Migrating the data

After you deploy a new controller for IBM Cloud Manager with OpenStack version 4.3, you can continue the process of migrating the data from the IBM Cloud Manager with OpenStack version 4.2 controller to the IBM Cloud Manager with OpenStack version 4.3 controller.

1. Ensure that the migration command can modify /etc/resolv.conf. If resolv.conf has a read-only flag, i, the migration fails at this step. To remove a read-only flag from the resolv.conf file, run the following command on the 4.3 controller nodes:

   chattr -i /etc/resolv.conf

2. Migrate any Cinder (storage) volume groups. For more information, see Migrating cinder volume groups to IBM Cloud Manager with OpenStack, version 4.3.
3. Go to the directory used to store the 4.3 topology files, which you created in the previous section. Change your-deployment-name to the name for your 4.3 deployment by running the following command on the deployment server:

   $ cd your-deployment-name

4. Run the following command on the deployment server to start the migration. Change your-topology-name-42 to the name of your 4.2 topology file. Change your-topology-name-43 to the name of your 4.3 topology file:

   $ knife os manage migrate topology your-topology-name-42.json your-topology-name-43.json

   This command provides the following options:

   • --icm42-controller-node-pass: Use this option to specify the password of user account 'root' on the source OpenStack controller node. This option is required when the node is using an SSH identity file for authentication in your topology file. Without this option, the migration uses the value of nodes.password in the 4.2 topology file for the source OpenStack controller node.
     Example:

     $ knife os manage migrate topology your-topology-name-42.json your-topology-name-43.json --icm42-controller-node-pass openstack1

   • --icm42-db-node-pass: Use this option to specify the password of user account 'root' on the source distributed database node. This option is required when the node is using an SSH identity file for authentication in your topology file. Without this option, the migration uses the value of nodes.password in the 4.2 topology file for the source distributed database node.
   • --icm42-ssp-node-pass: Use this option to specify the password of user account 'root' on the source self-service portal node. This option is required when the node is using an SSH identity file for authentication in your topology file. Without this option, the migration uses the value of nodes.password in the 4.2 topology file for the source self-service portal node.
   • --icm43-controller-node-pass: Use this option to specify the password of user account 'root' on the new 4.3 controller node. This option is required when the node is using an SSH identity file for authentication in your topology file. Without this option, the migration uses the value of nodes.password in the 4.3 topology file for the new 4.3 controller node.
   • --icm43-db-node-pass: Use this option to specify the password of user account 'root' on the new 4.3 distributed database node. This option is required when the node is using an SSH identity file for authentication in your topology file. Without this option, the migration uses the value of nodes.password in the 4.3 topology file for the new distributed database node.
   • --icm43-ssp-node-pass: Use this option to specify the password of user account 'root' on the new 4.3 self-service portal node. This option is required when the node is using an SSH identity file for authentication in your topology file. Without this option, the migration uses the value of nodes.password in the 4.3 topology file for the new self-service portal node.
   • --no-validation: This option indicates that when the nodes list or node runlist that is identified in the topology file conflicts with the list that is stored on the deployment Chef server, the upgrade should continue. Without this option, you are prompted whether to continue the migration. By default, you are prompted to confirm.
     Example:

     $ knife os manage migrate topology your-topology-name-42.json your-topology-name-43.json --no-validation

     Note: To avoid breaking the cloud unintentionally, you should use this option only when you don’t want to confirm.
   • --no-ssp-openstack-in-same-database: If you don’t use DB2® as the self-service portal database backend, you can ignore this option. This option indicates that the OpenStack and self-service portal are connecting to different DB2 database servers. Without this option, it means that they are connecting to the same DB2 server.
     Example:

     $ knife os manage migrate topology your-topology-name-42.json your-topology-name-43.json --no-ssp-openstack-in-same-database

     Important: If your environment is configured so that the source OpenStack and self-service portal are connecting to different DB2 database servers, the command knife os manage migrate topology does not migrate the database for the self-service portal. You must migrate data for the self-service portal from version 4.2 to 4.3 manually in a later step.
   • --icm42-ssp-node-ip: This option specifies the IP address of your 4.2 self-service portal node. This parameter is required when self-service portal is deployed in your environment. You can ignore this parameter if self-service portal is not deployed in your environment.
     Example:

     $ knife os manage migrate topology your-topology-name-42.json your-topology-name-43.json --icm42-ssp-node-ip x.x.x.x

5. You are prompted to shut down the source controller node. As part of the migration, the IP addresses of the source controller node are transferred to the 4.3 controller node. Before you continue, ensure that all of the useful data on the 4.2 server is transferred. Then, press Enter.
6. You are prompted to restart the 4.3 controller node. Before you continue, ensure that the applications on the 4.3 server are closed properly and other services (not OpenStack related services) or jobs are saved. Then, press Enter.
   Notes:

   1. If you keep receiving errors similar to the following output, more than 50 times, ensure that your 4.3 controller node is started successfully. Ensure that it is accessible for the deployment server. The error disappears automatically when the deployment server connects successfully to the 4.3 controller node.

      ERROR: Connection refused - connect(2)
      ERROR: /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/net-ssh-2.9.1/lib/net/ssh/transport/session.rb:70:in `initialize'
      /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/net-ssh-2.9.1/lib/net/ssh/transport/session.rb:70:in `open'
      /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/net-ssh-2.9.1/lib/net/ssh/transport/session.rb:70:in `block in initialize'
      /opt/chef/embedded/lib/ruby/1.9.1/timeout.rb:55:in `timeout'
      /opt/chef/embedded/lib/ruby/1.9.1/timeout.rb:100:in `timeout'
      /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/net-ssh-2.9.1/lib/net/ssh/transport/session.rb:67:in `initialize'
      /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/net-ssh-2.9.1/lib/net/ssh.rb:202:in `new'
      /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/net-ssh-2.9.1/lib/net/ssh.rb:202:in `start'
      /root/.chef/plugins/knife/os_manage_patches.rb:125:in `new_session'
      /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.8/lib/chef/monkey_patches/net-ssh-multi.rb:79:in `next_session'
      /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/net-ssh-multi-1.2.0/lib/net/ssh/multi/server.rb:138:in `session'
      /opt/chef/embedded/lib/ruby/gems/1.9.1/gems/net-ssh-multi-1.2.0/lib/net/ssh/multi/session_actions.rb:36:in `block (2 levels) in sessions'
      Reconnecting to <node ip> in 5 seconds...

   2. After the restart, the IP addresses on the 4.3 controller nodes are replaced by the corresponding IP addresses on the source controller nodes.

      The controller node is the node that has either the OpenStack controller, self-service portal, or both the OpenStack controller and self-service portal installed.

      For example, the fully qualified domain name (FQDN) of your 4.2 OpenStack controller node is os42.fqdn.com. The FQDN of your 4.3 OpenStack controller node is os43.fqdn.com. When your 4.2 controller node, os42.fqdn.com, is shut down in the previous step, the FQDN of your 4.3 controller node is updated to os42.fqdn.com when you restart the 4.3 controller node in this step.

      Similarly, you might have a 4.2 self-service portal node with the FQDN ssp42.fqdn.com. The FQDN of your 4.3 self-service portal node is ssp43.fqdn.com. Then, when your 4.2 self-service portal node, ssp42.fqdn.com, is shut down, the FQDN of your 4.3 self-service portal node is updated to ssp42.fqdn.com.

7. You are prompted to update the 4.3 topology. Press Enter to start.
   Important: You can run the knife os manage migrate topology command only one time. If you encounter any issue after this step, fix the updating topology problem that you encountered, and run the following command to re-update the topology:

   $ knife os manage update topology your-topology-name-43.json

8. If you used the --no-ssp-openstack-in-same-database option with the command knife os manage migrate topology in the previous steps, you must complete more steps to migrate the database for self-service portal manually. For more information, see Migrating self-service portal data.
9. If your IBM Cloud Manager with OpenStack 4.2 self-service portal is configured to use LDAP authentication, you must complete more steps to migrate the LDAP user for self-service portal. For more information, see Migrating LDAP for self-service portal.

http(s)://ssp42.fqdn.com:port number