Migration Guide

Because all Freezer content will be obsolete upon migrating to the new platform, it is recommended to stop Freezer jobs and eliminate historic backups.

(old-deployer)> source ~/backup.osrc
(old-deployer)> for id in $(freezer job-list -f value | awk '{print $1}')
  do freezer job-stop $id
done
(old-deployer)> for container in $(openstack container list -f value); do
  for backup in $(openstack object list $container -f value); do
    openstack object delete $container $backup
    echo "Deleting $backup"
  done
done

If your cloud includes VMware ESX compute clusters, save the EON service activation template for future reference, as the EON service will no longer exist once migration is complete.

(old-deployer)> source ~/service.osrc
(old-deployer)> eon get-activation-template \
  --filename ~/activationtemplate.json --type esxcluster

Obtain the HPE Helion OpenStack 5.SCP installation ISO and use the mount command to make its contents available on the existing deployer:

(old-deployer)> mkdir hos-5.scp
(old-deployer)> sudo mount HELION5SCP_ISO_FILE hos-5.scp
(old-deployer)> tar -xzvf hos-5.scp/hos/hlm-migration-tools.tar.gz
(old-deployer)> sudo umount hos-5.scp

Run the validation playbook to ensure that the current cloud load and configuration is compatible with the migration process:

(old-deployer)> cd hlm-migration-tools/ansible
(old-deployer)> ansible-playbook \
  -i ~/scratch/ansible/next/hos/ansible/hosts/verb_hosts \
  pre-migration-validations.yml

The validation playbook checks that:

Warning: Check Validation Results

Review the contents of /var/log/pre-migration-validations.log immediately to discover if any errors were identified while running the validation playbook. Any identified issues must be resolved before proceeding with the migration.

Set up SMT repository hosting on a SLES server external to your cloud so that operating system and software updates can be applied during migration without waiting for additional download steps.

Identify a candidate seed Control Node in the primary control plane. This node must meet the following requirements:

Consider the effect of control plane downtime on existing DHCP leases:

Prepare the cloud data model for migration:

If the intended seed node also currently hosts Neutron L3 routing services, evacuate the routers from the node so that it can be re-imaged without interruption to tenant networks.

Re-image the seed controller as a SLES-based system:

Transfer configuration and files from your existing cloud to the new seed node

On the new seed node, remove the package repository that was configured when its operating system was first installed. Then, mount the operating system image to make it available to the HPE Helion OpenStack installer.

Install HPE Helion OpenStack 5.SCP on the seed node by downloading and unpacking HPE Helion OpenStack 5.SCP installation content:

(seed)> cd ~
(seed)> mkdir -p hos-5.scp
(seed)> sudo mount HELION5SCP_ISO_FILE hos-5.scp
(seed)> tar -xf hos-5.scp/hos/hos-5.1.0-*.tar
(seed)> sudo mkdir -p /var/log/apache2
(seed)> cd ~/hos-5.1.0
(seed)> ./hos-init.bash

Update repository references of Compute Node as appropriate to point to the seed node.

If VMware ESX compute hosts are present in the cloud, encrypt your ESX login credentials for embedding in the data model. This will require use of the HOS_USER_PASSWORD_ENCRYPT_KEY environment variable and the hosencrypt.py script, which is also used for encrypting the following other data model elements:

The use of hosencrypt.py for encryption is required for VMware ESX credentials (unlike some of the items above, which may optionally be stored in plaintext.)

If you have used hosencrypt.py previously for any of the items above, then you have already selected an encryption key for use with your cloud. This encryption key must be exported into the environment variable HOS_USER_PASSWORD_ENCRYPT_KEY when the password is encrypted, and again before running playbooks such as site.yml. If this is your first time using such encryption, choose a new, unique encryption key and proceed:

(seed)> export HOS_USER_PASSWORD_ENCRYPT_KEY=ENCRYPTIONKEY
(seed)> ./hosencrypt.py
unencrypted value? <VCENTERPASSWORD>
@hos@U2FsdGVkX180/6dJIPPt49epntxAOFP0MtpjWsOaYzc=

Capture the resulting encrypted value and paste it into the password field of ~/helion/my_cloud/definition/data/pass_through.yml, replacing the value previously set there by EON. If you have questions about the structure or content in pass_through.yml, comments regarding its use are provided with the HPE Helion OpenStack 5.SCP example data models such as in ~/helion/examples/entry-scale-esx-kvm-vsa/data/pass_through.yml.

In your cloud's data model, edit the control plane definition and add a new data model entry for nova-placement-api into the cluster which already includes nova-api.

(seed)> cd ~/helion/my_cloud/definition/data
(seed)> vi control_plane.yml
(seed)> git commit -a -m "Adding nova-placement-api"

Prepare for running the migration playbook:

(seed)> cd ~/helion/hos/ansible
(seed)> ansible-playbook -i hosts/localhost config-processor-run.yml
(seed)> ansible-playbook -i hosts/localhost ready-deployment.yml

Initialize ansible host facts and ensure that the existing cloud is fully addressable by the new deployer:

(seed)> cd ~/scratch/ansible/next/hos/ansible
(seed)> ansible-playbook -i hosts/verb_hosts hlm-refresh-facts.yml

Note: OpenStack Clouds Only

The following step is only necessary on OpenStack clouds and should not be used in standalone Swift deployments.

Flush the Keystone token cache by running the following command on any node hosting the Keystone API service. (This may be the seed node in an entry-scale environment, or a dedicated controller node in a mid-scale environment.)

(controller)> sudo /opt/stack/service/keystone/venv/bin/keystone-manage token_flush

Then, prune the primary database to remove data that is no longer relevant:

(seed)> cd ~/scratch/ansible/next/hos/ansible
(seed)> ansible-playbook -i hosts/verb_hosts percona-prune.yml

If your cloud's data model is password-protected, use the following method to save the password in a local file before proceeding:

(seed)> touch ~/.vault_pass.txt
(seed)>  chmod 600 ~/.vault_pass.txt
(seed)>  vi ~/.vault_pass.txt

Ensure that the contents of the file are set to include only the plaintext vault password. Then, after saving it, run export ANSIBLE_VAULT_PASSWORD_FILE=~/.vault_pass.txt in preparation for upcoming steps.

Stop or pause OpenStack services on the control plane (excluding the seed that has been freshly imaged):

(seed)> cd ~/scratch/ansible/next/hos/ansible
(seed)> ./hlm-quiesce.sh --limit '!SEED_HOST'

The SEED_HOST name must exactly match the host name that is referenced in hosts/verb_hosts, such as ardana-cp1-c1-m1.

Create a database backup by retrieving MySQL database contents from a running database node in the database cluster.

(seed)> cd ~/scratch/ansible/next/hos/ansible
(seed)> ansible-playbook -i hosts/verb_hosts percona-vertica-removal-cleanup.yml
(seed)> ansible-playbook -i hosts/verb_hosts percona-export.yml \
  -e dbcontent=~/mysql_dump.sql

Re-image the remaining servers in the control plane.

The repos should now be set up on all servers. Verify that this is the case with the following:

(seed)> cd ~/scratch/ansible/next/hos/ansible
(seed)> ansible resources -a "zypper ref" --become

All issues with the repositories must be resolved before continuing. All servers except RHEL Compute Nodes should complete successfully. All SLES servers should reference the repo on port 79 on the new seed.

Create the log directory for the configuration processor, and then run the HPE Helion OpenStack 5.SCP installation. Enable database import from the snapshot that was captured from your cloud by using the dbcontent flag:

(seed)> mkdir -p /var/log/configuration_processor
(seed)> cd ~/scratch/ansible/next/hos/ansible
(seed)> ansible-playbook -i hosts/verb_hosts -vvv site.yml -e dbcontent=~/mysql_dump.sql

This will be a time-consuming installation, and should be allowed to complete without interruption. Once it is done, the cloud should again be operational, with the exception of monitoring components that will remain offline until the upgrade to HPE Helion OpenStack 8 is fully complete.

If OVSvApp nodes are present in the environment, they should now be re-imaged with an operating system installed from the SUSE Linux Enterprise Server 12 SP3 ISO. Follow the directions above regarding ESX (nova-proxy) nodes exactly, doing the same for OVSvApp nodes.

Note

Note that, while a VMware ESX host's OVSvApp node is offline, other running VMs on the same host will experience degraded network connectivity. To ensure maximum uptime, migrate all other VMs away from a host before reinstalling its OVSvApp node. Once the node is fully online again, the affected VMs can be returned to their original host.

After re-imaging an OVSvApp node, install HPE Helion OpenStack 5.SCP components on it from your seed using:

(seed)> ansible-playbook -i hosts/verb_hosts site.yml \
  -l 'OVSVAPP_HOSTS'

More than one OVSvApp host can be installed at once by separating their names using commas. Note that each host should be identified by its Ansible-friendly name, matching the way it is referred to in the hosts/verb_hosts file.

Deployer nodes offer limited disk space, and it is appropriate at this time to transfer the ~/mysql_dump.sql file to an external location outside the cloud (where it can be available in case of any recovery needs) and remove it from the seed node:

(seed)> rm ~/mysql_dump.sql

If desired, transfer the deployer role in the HPE Helion OpenStack 5.SCP cloud to a different node, such as one that originally served as a dedicated deployer.

Convert the helion Git repository to an openstack Git repository for use by Ardana:

(stack)> cd ~
(stack)> cp -r helion openstack
(stack)> cd openstack
(stack)> git checkout site

If your environment included a SES storage backend, remove all references to it from your data model. This may be done by using git revert COMMIT-ID to revert a specific commit including the SES backend definition, or git checkout hos -- FILENAME to restore an entire file to its original version (followed by git diff --staged to inspect the difference between files and ensure that you ar satisfied with the final condition of the configuration file.) Committing these edits will be necessary for the following files in the ~/openstack git repository:

Save a record of all other manual changes that have been previously committed to the hos/ansible directory, as you will need to reapply them later:

(stack)> git diff hos -- hos/ansible > /tmp/hos.diff

Forcibly undo all the changes identified:

(stack)> rm -rf hos/ansible
(stack)> git checkout hos -- hos/ansible

Reset the codebase to make it ready for Ardana, then transform the rest of the repository:

(stack)> git commit -a -m "Resetting codebase in prep for Ardana"
(stack)> git branch -m hos ardana
(stack)> git checkout ardana
(stack)> sed -i 's/hos/ardana/' .gitignore
(stack)> git commit -a -m "Prep for Ardana"
(stack)> git mv hos ardana
(stack)> git mv hos_extensions ardana_extensions
(stack)> for i in $(find -L my_cloud/config -xtype l)
  do ln -sfn $(readlink $i | sed 's/\/hos\//\/ardana\//') $i
done
(stack)> git commit -a -m "Conversion to Ardana"
(stack)> git checkout cp-persistent
(stack)> sed -i 's/component: helion-ca/component: ardana-ca/' \
  my_cloud/persistent_state/private_data_control-plane-1.yml
(stack)> sed -i 's/helion_internal_ca/ardana_internal_ca/' \
  my_cloud/persistent_state/private_data_control-plane-1.yml
(stack)> git commit -a -m "Conversion to Ardana"
(stack)> git checkout site
(stack)> git merge ardana -m "Conversion to Ardana"

Any merge conflicts that arise through this procedure can be addressed in the manner described in Book “Installing with Cloud Lifecycle Manager”, Chapter 10 “Using Git for Configuration Management”, Section 10.3 “Resolving Git merge conflicts”.

If the file /tmp/hos.diff contains changes that were saved prior to the repo conversion above, reinstate them in the ardana/ansible directory.

(stack)> if [ -s /tmp/hos.diff ]; then
  sed 's/ \([ab]\?[\/]\?\)hos\/ansible/ \1ardana\/ansible/g' /tmp/hos.diff | git apply
fi

If merge conflicts are reported, some files may need to be edited manually to reconcile the updates to file paths and directory structure that make the codebase suitable for upgrading to Ardana.Newton. Further information about merge operations can be found at Book “Installing with Cloud Lifecycle Manager”, Chapter 10 “Using Git for Configuration Management”, Section 10.3 “Resolving Git merge conflicts”.

(stack)> git add -A
(stack)> git commit -a -m "Reinstated hos playbook customizations (batch)"

Remove and archive the HPE Helion OpenStack 5.SCP-related content:

(stack)> mv ~/scratch ~/scratch.scp
(stack)> sudo rm /etc/apache2/sites-enabled/deployer_venv_server.conf

Prepare the ardana_packager working directory to include existing SUSE repositories:

(stack)> sudo mkdir -p /opt/ardana_packager/ardana/sles12/zypper
(stack)> sudo ln -s /opt/hlm_packager/hlm /opt/ardana_packager/hlm
(stack)> sudo ln -s /opt/hlm_packager/hlm/sles12/zypper/OS \
  /opt/ardana_packager/ardana/sles12/zypper/OS

Install Ardana.Newton content onto the deployer by mounting the installation media and running the following commands:

(stack)> cd ~
(stack)> sudo mkdir -p /media/ardana-0.35.0
(stack)> sudo mount ~/HELION5CLM_ISO_FILE /media/ardana-0.35.0
(stack)> tar -xf /media/ardana-0.35.0/ardana/ardana-0.35.0*.tar
(stack)> cd ardana-0.35.0
(stack)> ./ardana-init.bash

If merge conflicts are reported, some files may need to be edited manually to reconcile updates being introduced to the playbooks by the Ardana.Newton codebase. Use caution when evaluating these merge conflicts, and ensure that the only changes given priority over the incoming playbooks are those which are specifically relevant to your cloud's configuration and should be retained into the future. Further information about merge operations can be found at Book “Installing with Cloud Lifecycle Manager”, Chapter 10 “Using Git for Configuration Management”, Section 10.3 “Resolving Git merge conflicts”.

Install Ardana.Newton:

(stack)> cd ~/openstack/ardana/ansible
(stack)> ansible-playbook -i hosts/localhost config-processor-run.yml
(stack)> ansible-playbook -i hosts/localhost ready-deployment.yml

(stack)> cd ~/scratch.scp/ansible/next/hos/ansible/
(stack)> ansible-playbook -i hosts/verb_hosts osconfig-iptables-rename.yml
(stack)> ansible -i hosts/verb_hosts resources --become \
  -a "sed -i 's/helion/ardana/' /etc/iproute2/rt_tables"

Because the OpenStack service versions are comparable between HPE Helion OpenStack 5.0.x and Ardana.Newton, it is not necessary to run the entire deploy/upgrade playbook for Ardana.Newton at this time.

Create the ardana user throughout all nodes in the cloud:

(stack)> cd ~/scratch/ansible/next/ardana/ansible
(stack)> ansible-playbook -i hosts/verb_hosts ardana-user-create.yml

Mount the HPE Helion OpenStack 8 installation media on the host (after copying the ISO file into the user's home directory)

(stack)> sudo mkdir -p /media/cloud
(stack)> echo /home/stack/HPE-HELION-OPENSTACK-8-x86_64-GM-DVD1.iso \
  /media/cloud iso9660 loop 0 0 | sudo tee -a /etc/fstab
(stack)> sudo mount -a

Add the contents of the ISO as a Zypper repository:

(stack)> sudo zypper ar -G -f file:/media/cloud Cloud
(stack)> sudo zypper refresh

Begin the installation:

(stack)> sudo zypper -n in patterns-cloud-ardana

Before continuing the installation, add a password of your choosing to the new ardana user:

(stack)> sudo passwd ardana

Then, exit your current session on the deployer and open a new session as the ardana user, logging in with the password that you just established. From this point on, the ardana user will be used for all operations, and the stack user should be considered deprecated.

To ensure that the stack user does not continue to be used, locking its account with the following command is highly recommended:

ardana > sudo usermod -L stack
ardana > sudo rm -rf ~stack/.ssh/authorized_keys
ardana > sudo mv ~stack/scratch ~stack/scratch.newton
ardana > sudo mv ~stack/helion ~stack/helion.newton

Continue the installation as the ardana user:

ardana > ARDANA_INIT_AUTO=1 /usr/bin/ardana-init

If merge conflicts are reported, some files may need to be edited manually to reconcile the difference between playbook versions with respect to manual changes previously made for your cloud. Use caution when evaluating these merge conflicts, and ensure that the only changes given priority over the incoming playbooks are those which are specifically relevant to your cloud's configuration and should be retained into the future. Further information about merge operations can be found at Book “Installing with Cloud Lifecycle Manager”, Chapter 10 “Using Git for Configuration Management”, Section 10.3 “Resolving Git merge conflicts”

The installation process creates the directory /srv/www/suse-12.3/x86_64/repos/PTF and adds it as a software repository. To enable a successful migration, you must add required Program Temporary Fix (PTF) RPM packages to this repository manually. These packages are provided to you by SUSE via an active L3 support contract.

To add the PTF RPMs manually, the RPMs should be copied into the /srv/www/suse-12.3/x86_64/repos/PTF directory. For example, if the downloaded RPMs are located in /tmp/PTF:

ardana > sudo cp /tmp/PTF/*.rpm /srv/www/suse-12.3/x86_64/repos/PTF

Apply the PTF packages obtained in the previous step and confirm that they install correctly:

ardana > cd ~/openstack/ardana/ansible
ardana > ansible-playbook -i hosts/localhost deployer-init.yml
ardana > sudo zypper refresh PTF
ardana > sudo zypper dup --from PTF
ardana > sudo zypper in ardana-ses
ardana > rpm -qa | grep PTF

Ensure that all migration RPMs starting with the prefix "ardana" available via your SUSE support contract are present in the resulting list. If any are missing, repeat the above process or contact technical support before continuing.

Apply the updates received via PTF packages to your active cloud:

ardana > /usr/bin/ardana-init

Set the default Glance store to hlm-default-store so that your existing image content remains accessible following the upgrade.

ardana > cd ~/openstack/ardana/ansible
ardana > sed -i 's/ardana-default-store/hlm-default-store/' \
  roles/GLA-API/defaults/main.yml

Update certificate references to use the new "ardana" name:

ardana > sed -i 's/cert-file: helion/cert-file: ardana/' \
  ../../my_cloud/definition/data/network_groups.yml \
  ../../my_cloud/definition/data/control_plane.yml

Adjust data model to install cassandra instead of vertica. Manually replace vertica with cassandra in the service-components list, and remove any entry for ops-console-monitor:

ardana > vi ../../my_cloud/definition/data/control_plane.yml

In files where a cassandra_db partition exists, manually update its consumer name from vertica to cassandra and add an identical consumer block to the cassandra_log partition definition with:

ardana > vi ../../my_cloud/definition/data/disks_*

For example:

- name: cassandra_db
  size: 20%
  mount: /var/cassandra/data
  fstype: ext4
  mkfs-opts: -O large_file
  consumer:
    name: cassandra

- name: cassandra_log
  size: 1%
  mount: /var/cassandra/commitlog
  fstype: ext4
  mkfs-opts: -O large_file
  consumer:
    name: cassandra

If your environment includes a SES backend, add configuration files to enable it based on the Book “Installing with Cloud Lifecycle Manager”, Chapter 23 “Integrations”, Section 23.3 “SUSE Enterprise Storage Integration” instructions. (However, the site.yml and ardana-reconfigure.yml playbooks should not be used at this time.)

Save the updates to the data model:

ardana > git commit -a -m 'Updated data model'

Build the ~/scratch directory for the upgrade:

ardana > ansible-playbook -i hosts/localhost config-processor-run.yml
ardana > ansible-playbook -i hosts/localhost ready-deployment.yml

Prepare the servers for Pike infrastructure:

ardana > cd ~/scratch/ansible/next/ardana/ansible
ardana > ansible-playbook -i hosts/verb_hosts FND-AP2-vhosts-transition.yml
ardana > sudo rename helion ardana /tmp/helion_*
ardana > sudo rename helion ardana /tmp/ardana_*/helion*

Set up and verify package repositories for installation:

ardana > sudo ln -s /media/cloud /srv/www/suse-12.3/x86_64/repos/Cloud
ardana > sudo ln -s /opt/hlm_packager/hlm/sles12/zypper/extras/sles12sp3-ceph-updates \
  /srv/www/suse-12.3/x86_64/repos/sles12sp3-ceph-updates
ardana > ansible-playbook -i hosts/verb_hosts ardana-replace-legacy-repos.yml

Check that the repos have been properly set up, and that refreshing them succeeds for all SLES cloud nodes:

ardana > ansible resources -m shell -a "zypper ref" --become

If your environment includes RHEL Compute Nodes, prepare your deployer for provisioning OpenStack services on them by following the steps described in Book “Installing with Cloud Lifecycle Manager”, Chapter 22 “Installing RHEL Compute”, Section 22.4 “Using RHEL as a Compute Node”.

Note

If you opt to install an SMT server on your new deployer for mirroring the CentOS repo, you must first run the command sudo ln -s /var/lib/mysql/mysql.sock /var/run/mysql/mysql.sock to enable SMT access to the database. (This access is enabled permanently upon completion of the upgrade, but must be manually set up if needed at this time.)

If the CA Management procedure is used to set up a root CA certificate in support of the deployer SMT server, you must immediately follow it by running sudo ln -s /etc/ssl/ca-bundle.pem /etc/ssl/certs/ca-certificates.crt before proceeding with the software upgrade.

Run the HPE Helion OpenStack 8 upgrade playbook:

ardana > ansible-playbook -i hosts/verb_hosts -vvv ardana-upgrade-from-legacy.yml

Note that the ardana-upgrade-from-legacy.yml playbook is not guaranteed to be idempotent, and re-running it upon a failure may produce new errors. If this playbook fails, please contact customer support and be prepared to share details of the failure from the contents of ~/.ansible/ansible.log to determine appropriate next steps.

Now that the upgrade has completed, it will be necessary to reboot the control plane nodes in your cloud for changes to take effect. At this time, reboot only the control plane nodes (not compute nodes) in your cloud per the instructions in Book “Operations Guide”, Chapter 13 “System Maintenance”, Section 13.1 “Planned System Maintenance”, Section 13.1.1 “Whole Cloud Maintenance”, Section 13.1.1.1 “Bringing Down Your Cloud: Services Down Method”.

If your cloud includes OpenStack-provisioned load balancers, the following step is necessary to update the Amphora load balancer image used by the Octavia service:

ardana > ansible-playbook -i hosts/verb_hosts -vvv service-guest-image \
  -e service_package=$(ls /srv/www/suse-12.3/x86_64/repos/PTF/openstack-octavia-amphora-image*.rpm)

After updating the Amphora image with the above playbook, the following steps are recommended to confirm that load balancer functionality works as expected. (This will ensure that your workloads remain available through the upcoming reboots of compute nodes.)

You may now proceed to reboot the compute nodes in your cloud for all changes to fully take effect and re-enable normal behavior. Continue to refer to the steps described in Book “Operations Guide”, Chapter 13 “System Maintenance”, Section 13.1 “Planned System Maintenance”, Section 13.1.1 “Whole Cloud Maintenance”, Section 13.1.1.1 “Bringing Down Your Cloud: Services Down Method”.

At this time, the PTF and other temporary packages can be removed:

ardana > cd ~/scratch/ansible/next/ardana/ansible
ardana > ansible -i hosts/verb_hosts resources --become -m shell \
  -a "zypper rr sles12sp3-ceph-updates || true"
ardana > sudo rm /srv/www/suse-12.3/x86_64/repos/sles12sp3-ceph-updates
ardana > sudo rm -rf /srv/www/suse-12.3/x86_64/repos/PTF/*.rpm
ardana > cd ~/openstack/ardana/ansible
ardana > ansible-playbook -i hosts/localhost deployer-init.yml
ardana > sudo zypper refresh PTF
ardana > sudo zypper dup --from Cloud

Note

When running sudo zypper dup --from Cloud, warnings will appear about packages being downgraded. This is expected and should be acknowledged as you proceed.

Determine how to handle modified policy files which restrict the admin user's privileges more tightly than in previous releases:

With this upgrade, the policy.json files have been aligned with OpenStack Pike. When running OpenStack commands an operator may see messages saying Policy doesn't allow ... such as:

Policy doesn't allow volume_extension:services:index to be performed

In this case the operator can be given permission by adding a role to the user using the openstack role add command, for example:

ardana > openstack role add --user USER_NAME \
  --project PROJECT_NAME cinder_admin

Role assignments should be carefully considered. In an environment which requires separation of duties, each operator should be assigned only the roles they require to perform their duties and should use their own user account to perform their administrative tasks. For more information see the Book “Security Guide”, Chapter 4 “HPE Helion OpenStack®: Service Admin Role Segregation in the Identity Service”.

Before applying updates to your cloud, you should replace the repositories configured on each node during the migration with links to an SMT server that mirrors the latest versions of your software. To begin this process, register your deployer node and install the HPE Helion OpenStack extension as described in Book “Installing with Cloud Lifecycle Manager”, Chapter 3 “Installing the Cloud Lifecycle Manager server”, Section 3.5.2 “Installing the HPE Helion OpenStack Extension”.

The easiest way to provide the required repositories on the Cloud Lifecycle Manager Server is to configure it as an SMT server as described in Book “Installing with Cloud Lifecycle Manager”, Chapter 4 “Installing and Setting Up an SMT Server on the Cloud Lifecycle Manager server (Optional)”. Alternatives to setting up an SMT server are described in Book “Installing with Cloud Lifecycle Manager”, Chapter 5 “Software Repository Setup”.

Next, use the following commands to replace the original ISO repositories with the latest package sources provided by SUSE:

ardana > cd ~/scratch/ansible/next/ardana/ansible
ardana > sudo rm /opt/hlm_packager/hlm/sles12/zypper/OS /srv/www/suse-12.3/x86_64/repos/Cloud
ardana > ansible resources -i hosts/verb_hosts -m shell \
  -a "zypper rr Cloud; zypper rr SLES-OS || true" --become
ardana > ansible-playbook -i hosts/verb_hosts _osconfig-setup-repos.yml

Ensure that the "Cloud" repository has been replaced by the following repositories on all SLES nodes:

Finally, apply the latest versions of software packages using the process described in Book “Operations Guide”, Chapter 13 “System Maintenance”, Section 13.3 “Cloud Lifecycle Manager Maintenance Update Procedure”.