Havana to Juno: OpenStack Upgrade Procedures

Version 73

    Document number: E60697

    This article describes upgrade processes of an OpenStack setup from Havana to Juno.

    Important Note

     

    The contents of this document, especially the manual upgrade steps, apply only to the Oracle Solaris 11.2 SRU10 release. They do not apply to subsequent SRU releases beginning with the Oracle Solaris 11.2 SRU12 version, where upgrade processes are automated with minimal manual configuration involved. For information and instructions that apply to the SRU12 release, refer to its accompanying Readme documentation.

     

    Overview

     

    Juno is the OpenStack version that is available in the Oracle Solaris 11.2 SRU10 release. The processes described in this document cover the following OpenStack components:

    • Compute (Nova)
    • Block Storage (Cinder)
    • Object Storage (Swift)
    • Networking (Neutron)
    • Dashboard (Horizon)
    • Identity Service (Keystone)
    • Image Service (Glance)
    • Orchestration (Heat)

    For a fuller description of the features that are available in Juno, see http://www.openstack.org/software/Juno/.

     

    Prerequisite

     

    You must install Oracle Solaris 11.2 SRU10 on all your OpenStack systems.

    For instructions, log in to your My Oracle Support account. Go to the Oracle Solaris 11.2 Support Repository Updates (SRU) Index (Doc ID 1672221.1) and click the Readme and Install Guide links.

     

    Upgrade Notes

     

    • Stop all OpenStack services before you upgrade. Any OpenStack services left running during the upgrade might cause problems when you reboot the system.
    • Create backups of the Havana configuration files as well as of the databases.
    • After you upgrade to Juno, each component's configuration directory (/etc/<component>) would contain a combination of Havana based files and Juno based files.
      • Juno based configuration files are named <filename>.new.
      • Havana based configuration files remain untouched during the upgrade.
    • When upgrading, begin with the Keystone component first. After upgrading Keystone, you can proceed with upgrading the rest of the components on that node as well as on other nodes.
    • Before updating the databases to use UTF-8 character set and utf8_general_ci collate settings, complete the migration of the EVS database to Neutron database first.

     

    Description of the Upgrade Procedures

     

    This document uses the "upgrade by system or node" approach. This approach consists of the following steps:

    • Stopping the OpenStack services on the node.
    • Updating all the OpenStack components on that node.
    • Migrating configuration settings per component to Juno.
    • Converting existing databases on the system by running the database conversion script per database.
    • Restarting the services.

     

    Upgrade Steps

     

    NOTE: The Keystone component is the first component to be upgraded. Typically, Keystone is installed on the system that is designated as the controller. Thus, perform these steps first on the controller node. Then, proceed with upgrading the compute node and the storage node.

    1. Stop the OpenStack services that are running on the system.
      Identify the OpenStack services on the system first, then disable the services one by one.
      # svcs -a | grep openstack
      # svcadm disable -s <openstack-service>
    2. Update all the OpenStack components on that system.
      # pkg update
    3. Prepare the configuration files for the components on the system.
      a. Backup the Havana configuration files.
      b. Replace the current Havana configuration files with the corresponding Juno configuration files.
    4. Migrate the Havana parameter settings to the Juno configuration files.
      Refer to the section "Juno Configuration Files With Migrated Havana Settings" to know how Havana parameters are merged into Juno.
    5. Convert databases existing on the system by using the provided script. Refer to the section "Script to Convert MySQL Databases" for details on how to use the script.
    6. Restart the OpenStack services on the node.

     

    Juno Configuration Files With Migrated Havana Settings

     

    The migration of Havana settings to Juno configuration files involves two actions:

    • Mapping Havana parameters to Juno.
      Some Havana parameter names have changed in Juno. Other Havana parameters might have retained their names, but have been moved to a new section in the corresponding Juno file. Still other Havana parameters in a Havana file might have been moved over to a different Juno configuration file. Thus, you would need to ensure that these Havana settings are mapped or moved to their equivalent parameters in Juno. In the following files, parameters that have had changes to their names, sections, and files from Havana to Juno are marked with asterisks for easier identification.
    • Preserving Havana parameters in Juno
      Most Havana parameters remain the same in Juno file. You would need to retain the same Havana settings listed below in the equivalent parameters in Juno.

     

    Keystone

     

    /etc/keystone/keystone.conf

    • Parameters with asterisks under the [database] section are taken from the [sql] section in the corresponding Havana file.
    • Preserve the rest of the Havana settings under the [DEFAULT] section.

    The Juno file would resemble the following:

    [database]
    connection*
    idle_timeout*

    [DEFAULT]
    public_workers
    admin_workers

     

    Neutron

     

    /etc/neutron/l3_agent.ini

    • Preserve the Havana setting under the [DEFAULT] section.

    The Juno file would resemble the following:

    [DEFAULT]
    enable_metadata_proxy

     

    /etc/neutron/metadata_agent.ini

    • Preserve the Havana settings under the [DEFAULT] section.

    The Juno file would resemble the following:

    [DEFAULT]
    auth_url
    auth_region
    admin_tenant_name
    admin_user
    admin_password
    metadata_workers

     

    /etc/neutron/neutron.conf

    • Preserve the Havana settings under the following sections:
      • [DEFAULT]
      • [keystone_authtoken]
      • [database]

    The Juno file would resemble the following:

    [DEFAULT]
    lock_path

    [keystone_authtoken]
    auth_uri
    identity_uri
    admin_tenant_name
    admin_user
    admin_password
    signing_dir

    [database]
    connection

     

    Do the following:

    1. Migrate the EVS database to the Neutron database.
      # su - neutron -c "/usr/lib/neutron/evs-neutron-migration"
    2. Stamp the Neutron database
      # su - neutron -c "/usr/bin/neutron-db-manage --config-file /etc/neutron/neutron.conf \
      --config-file /etc/neutron/plugins/evs/evs_plugin.ini stamp juno"

     

    Glance

     

    /etc/glance/glance-api.conf

    • Parameters with asterisks under the [database] section are taken from the [DEFAULT] section in the corresponding Havana file and renamed from:
      • sql_connection
      • sql_idle_timeout
    • Preserve the Havana settings under the following sections:
      • [DEFAULT]
      • [keystone_authtoken]
      • [glance_store]

    The Juno file would resemble the following:

    [database]
    connection*
    idle_timeout*

    [DEFAULT]
    default_store
    bind_host
    bind_port
    log_file
    backlog
    workers
    registry_host
    registry_port
    registry_client_protocol
    rabbit_host
    rabbit_port
    rabbit_use_ssl
    rabbit_userid
    rabbit_password
    rabbit_virtual_host
    rabbit_notification_exchange
    rabbit_notification_topic
    rabbit_durable_queues
    qpid_notification_exchange
    qpid_notification_topic
    qpid_hostname
    qpid_port
    qpid_username
    qpid_password
    qpid_sasl_mechanisms
    qpid_reconnect_timeout
    qpid_reconnect_limit
    qpid_reconnect_interval_min
    qpid_reconnect_interval_max
    qpid_reconnect_interval
    qpid_heartbeat
    qpid_protocol
    qpid_tcp_nodelay
    delayed_delete
    scrub_time
    scrubber_datadir
    image_cache_dir

    [keystone_authtoken]
    auth_uri
    identity_uri
    admin_tenant_name
    admin_user
    admin_password
    revocation_cache_time
    signing_dir

    [glance_store]
    filesystem_store_datadir
    swift_store_auth_version
    swift_store_auth_address
    swift_store_user
    swift_store_key
    swift_store_container
    swift_store_create_container_on_put
    swift_store_large_object_size
    swift_store_large_object_chunk_size
    swift_enable_snet
    s3_store_host
    s3_store_access_key
    s3_store_secret_key
    s3_store_bucket
    s3_store_create_bucket_on_put
    sheepdog_store_address
    sheepdog_store_port
    sheepdog_store_chunk_size

     

    /etc/glance/glance-cache.conf

    • Preserve the Havana settings under the [DEFAULT] section.

    The Juno file would resemble the following:

    [DEFAULT]
    log_file
    image_cache_dir
    image_cache_stall_time
    image_cache_max_size
    registry_host
    registry_port
    auth_url
    admin_tenant_name
    admin_user
    admin_password
    filesystem_store_datadir
    swift_store_auth_version
    swift_store_auth_address
    swift_store_user
    swift_store_key
    swift_store_container
    swift_store_create_container_on_put
    swift_store_large_object_size
    swift_store_large_object_chunk_size
    swift_enable_snet
    s3_store_host
    s3_store_access_key
    s3_store_secret_key
    s3_store_bucket
    s3_store_create_bucket_on_put

     

    /etc/glance/glance-registry.conf

    • Parameters with asterisks under the [database] section are taken from the [DEFAULT]section in the corresponding Havana file and renamed from:
      • sql_connection
      • sql_idle_timeout
    • Preserve the Havana settings under the following sections:
      • [DEFAULT]
      • [keystone_authtoken]

    The Juno file would resemble the following:

    [database]
    connection*
    idle_timeout*

    [DEFAULT]
    workers
    rabbit_host
    rabbit_port
    rabbit_use_ssal
    rabbit_userid
    rabbit_password
    rabbit_virtual_host
    rabbit_notification_exchange
    rabbit_notification_topic
    rabbit_durable_queues
    qpid_notification_exchange
    qpid_notification_topic
    qpid_hostname
    qpid_port
    qpid_username
    qpid_password
    qpid_sasl_mechanisms
    qpid_reconnect_timeout
    qpid_reconnect_limit
    qpid_reconnect_interval_min
    qpid_reconnect_interval_max
    qpid_reconnect_interval
    qpid_heartbeat
    qpid_protocol
    qpid_tcp_nodelay

    [keystone_authtoken]
    auth_uri
    identity_uri
    admin_tenant_name
    admin_user
    admin_password
    signing_dir

     

    /etc/glance/glance-scrubber.conf

    • Preserve the Havana settings under the following sections:
      • [DEFAULT]
      • [database]
      • [glance_store]

    The Juno file would resemble the following:

    [DEFAULT]
    log_file
    wakeup_time
    scrubber_datadir
    cleanup_scrubber
    cleanup_scrubber_time
    registry_host
    registry_port
    auth_url
    admin_tenant_name
    admin_user
    admin_password

    [database]
    connection

    [glance_store]
    filesystem_store_datadir

     

    Cinder

     

    /etc/cinder/cinder.conf

    • Parameters with asterisks under [keystone_authtoken] are taken from /etc/cinder/api-paste.ini of Havana, if these existed under the [filter:authtoken] section.
    • Some parameters with asterisks under the [DEFAULT] section are ZFSSA parameters taken from the same section in the corresponding Havana file but were renamed as follows:
      • san_ip renamed from zfssa_auth_user
      • san_login renamed from zfssa_auth_password
      • san_password renamed from zfssa_host
    • Preserve the other Havana settings under the following sections:
      • [DEFAULT]
      • [database]

    The Juno file would resemble the following:

    [keystone_authtoken]
    auth_uri*
    identity_uri*
    admin_user*
    admin_password*
    admin_tenant_name*
    signing_dir*

    [DEFAULT]
    san_ip*
    san_login*
    san_password*

    osapi_volume_workers
    auth_strategy
    san_is_local
    volume_driver

    [database]
    connection

     

    Heat

     

    /etc/heat/heat.conf

    • Parameters with asterisks under [keystone_authtoken] are taken from /etc/heat/api-paste.ini of Havana, if these existed under the [filter:authtoken] section.
    • Parameters with asterisks under the [database] section are taken from the [DEFAULT]section in the corresponding Havana file and renamed from:
      • sql_connection
      • sql_idle_timeout
    • Preserve the other Havana settings under the [keystone_authtoken]section.
    [keystone_authtoken]
    auth_uri*
    identity_uri*
    admin_tenant_name*
    admin_user*
    admin_password*
    signing_dir

    [database]
    connection*
    idle_timeout*

     

    Nova

     

    /etc/nova/nova.conf

    • Parameters with asterisks under [keystone_authtoken] are taken from /etc/nova/api-paste.ini of Havana, if these existed under the [filter:authtoken] section.
    • Preserve the other Havana settings under the following sections:
      • [DEFAULT]
      • [conductor]
      • [database]
      • [neutron]

    The Juno file would resemble the following:

    [DEFAULT]
    ec2_workers
    osapi_compute_workers
    metadata_workers
    lock_path
    novncproxy_base_url
    [conductor]

    workers

    [database]
    connection

    [keystone_authtoken]
    auth_uri*
    signing_dir*
    identity_uri*
    admin_user*
    admin_password*
    admin_tenant_name*
    auth_version*

    [neutron]
    service_metadata_proxy

     

    Swift

     

    /etc/swift/account-server.conf

    • Preserve the other Havana settings under the [DEFAULT] section.

    The Juno file would resemble the following:

    [DEFAULT]
    bind_port = 6002
    workers = 1

     

    /etc/swift/container-server.conf

    • Preserve the other Havana settings under the [DEFAULT] section.

    The Juno file would resemble the following:

    [DEFAULT]
    bind_port = 6001
    workers = 1

     

    /etc/swift/dispersion.conf

    • Preserve the other Havana settings under the [dispersion] section.

    The Juno file would resemble the following:

    [dispersion]
    auth_url = http://localhost:8080/auth/v1.0
    auth_user = test:tester
    auth_key = testing

     

    /etc/swift/object-server.conf

    • Preserve the other Havana settings under the [DEFAULT] section.

    The Juno file would resemble the following:

    [DEFAULT]
    bind_port = 6000
    workers = 1

     

    /etc/swift/proxy-server.conf

    • Preserve the other Havana settings under the following sections:
      • [DEFAULT]
      • [filter:authtoken]

    The Juno file would resemble the following:

    [DEFAULT]
    bind_port

    [filter:authtoken]
    auth_uri
    identity_uri
    admin_tenant_name
    admin_user
    admin_password
    delay_auth_decision
    cache
    include_service_catalog
    signing_dir

     

    /etc/swift/swift.conf

    • Preserve the other Havana settings under the following sections:
      • [swift-hash]
      • [storage-policy:0]

    The Juno file would resemble the following:

    [swift-hash]
    swift_hash_path_suffix = changeme
    swift_hash_path_prefix = changeme

    [storage-policy:0]
    name = Policy-0
    default = yes

     

    Script to Convert MySQL Databases

     

    The following OpenStack components have databases:

    • Keystone
    • Glance
    • Neutron
    • Nova

    Each of these databases need to be converted to use the UTF8 character set. Customize the script for a specific database so that the script converts that database on the system. Do the following steps:

    1. Determine the databases that need to be converted on a specific node.
    2. Repeat the following steps for every database to be converted on the system.
      a. Edit the script by assigning values to the following parameters pertaining to the database. These parameters are at the end of the script.
          * db_hostname
          * db_username
          * dbpassword
          * database
      b. Run the script.

      For example, on a system with Keystone and Glance, you would run the script twice. Prior to each run, you would assign settings to the 4 parameters appropriate first to Keystone, and then to Glance.

     

    #!/usr/bin/python

    #
    # Copyright (c) 2015, Oracle and/or its affiliates. All rights reserved.
    #

    """ Convert MySQL tables to use utf8
    """
    import MySQLdb
    def alter_mysql_tables(db_hostname, db_username, db_password, database):
        db = MySQLdb.connect(host=db_hostname, user=db_username,
                              passwd=db_password, db=database)
        cursor = db.cursor()
        cursor.execute("SHOW table status")
        cursor.execute("ALTER DATABASE %s CHARACTER SET = 'utf8'" % database)
        cursor.execute("ALTER DATABASE %s COLLATE = 'utf8_general_ci'" % database)
        cursor.execute("SHOW tables")
        output = cursor.fetchall()
        if output:
            cursor.execute("SET foreign_key_checks = 0")
            for item in output:
                cursor.execute("ALTER TABLE %s.%s CONVERT TO "
                                "CHARACTER SET 'utf8', COLLATE 'utf8_general_ci'"
                                % (database, item[0]))
            cursor.execute("SET foreign_key_checks = 1")
            db.commit()
            db.close()

    if __name__ == "__main__":
        # Fill in the values below from the component's configuration file
        alter_mysql_tables(db_hostname, db_username, db_password, database)