Applies to SUSE OpenStack Cloud 8

33 Support #

Find solutions for the most common pitfalls and technical details on how to create a support request for SUSE OpenStack Cloud here.

33.1 FAQ #

1. Node Deployment

Q: How to Disable the YaST Installer Self-Update when deploying nodes?

Prior to starting an installation, the YaST installer can update itself if respective updates are available. By default this feature is enabled. In case of problems with this feature, disable it as follows:

Open ~/openstack/ardana/ansible/roles/cobbler/templates/sles.grub.j2 with an editor and add self_update=0 to the line starting with linuxefi. The results needs to look like the following:

linuxefi images/{{ sles_profile_name }}-x86_64/linux ifcfg={{ item[0] }}=dhcp install=http://{{ cobbler_server_ip_addr }}:79/cblr/ks_mirror/{{ sles_profile_name }} self_update=0 AutoYaST2=http://{{ cobbler_server_ip_addr }}:79/cblr/svc/op/ks/system/{{ item[1] }}

Commit your changes:

ardana > git commit -m "Disable Yast Self Update feature" \
~/openstack/ardana/ansible/roles/cobbler/templates/sles.grub.j2

If you need to reenable the installer self-update, remove self_update=0 and commit the changes.

33.2 Support #

Before contacting support to help you with a problem on your cloud, it is strongly recommended that you gather as much information about your system and the problem as possible. For this purpose, SUSE OpenStack Cloud ships with a tool called supportconfig. It gathers system information such as the current kernel version being used, the hardware, RPM database, partitions, and other items. supportconfig also collects the most important log files, making it easier for the supporters to identify and solve your problem.

It is recommended to always run supportconfig on the CLM Server and on the Control Node(s). If a Compute Node or a Storage Node is part of the problem, run supportconfig on the affected node as well. For details on how to run supportconfig, see https://documentation.suse.com/sles/12-SP5/single-html/SLES-admin/#cha-adm-support.

33.2.1 Applying PTFs (Program Temporary Fixes) Provided by the SUSE L3 Support #

Under certain circumstances, the SUSE support may provide temporary fixes, the so-called PTFs, to customers with an L3 support contract. These PTFs are provided as RPM packages. To make them available on all nodes in SUSE OpenStack Cloud, proceed as follows. If you prefer to test them first on a single node, see Section 33.2.2, “ Testing PTFs (Program Temporary Fixes) on a Single Node ”.

Download the packages from the location provided by the SUSE L3 Support to a temporary location on the CLM Server.
Move the packages from the temporary download location to the following directories on the CLM Server:
“noarch” packages (*.noarch.rpm):
/srv/www/suse-12.2/x86_64/repos/PTF/rpm/noarch/
“x86_64” packages (*.x86_64.rpm)
/srv/www/suse-12.2/x86_64/repos/PTF/rpm/x86_64/
Create or update the repository metadata:
```
ardana > createrepo-cloud-ptf
```
To deploy the updates, proceed as described in Book “Operations Guide”, Chapter 13 “System Maintenance”, Section 13.3 “Cloud Lifecycle Manager Maintenance Update Procedure” and refresh the PTF repository before installing package updates on a node:
```
ardana > zypper refresh -fr PTF
```

33.2.2 Testing PTFs (Program Temporary Fixes) on a Single Node #

If you want to test a PTF (Program Temporary Fix) before deploying it on all nodes, if you want to verify that it fixes a certain issue, you can manually install the PTF on a single node.

In the following procedure, a PTF named venv-openstack-nova-x86_64-ptf.rpm, containing a fix for Nova, is installed on the Compute Node 01.

Procedure 33.1: Testing a Fix for Nova #

Check the version number of the package(s) that will be upgraded with the PTF. Run the following command on the deployer node:
```
ardana > rpm -q venv-openstack-nova-x86_64
```
Install the PTF on the deployer node:
```
tux > sudo zypper up ./venv-openstack-nova-x86_64-ptf.rpm
```
This will install a new TAR archive in /opt/ardana_packager/ardana-8/sles_venv/x86_64/.
Register the TAR archive with the indexer:
```
tux > sudo  create_index --dir \
      /opt/ardana_packager/ardana-8/sles_venv/x86_64
```
This will update the indexer /opt/ardana_packager/ardana-8/sles_venv/x86_64/packages.

Deploy the fix on Compute Node 01:

Check whether the fix can be deployed on a single Compute Node without updating the Control Nodes:

ardana > cd ~/scratch/ansible/next/ardana/ansible
ardana > ansible-playbook -i hosts/verb_hosts nova-upgrade.yml \
--limit=inputmodel-ccp-compute0001-mgmt --list-hosts

If the previous test passes, install the fix:

ardana > ansible-playbook -i hosts/verb_hosts nova-upgrade.yml \
--limit=inputmodel-ccp-compute0001-mgmt

Validate the fix, for example by logging in to the Compute Node to check the log files:
```
ardana > ssh ardana@inputmodel-ccp-compute0001-mgmt
```
In case your tests are positive, install the PTF on all nodes as described in Section 33.2.1, “ Applying PTFs (Program Temporary Fixes) Provided by the SUSE L3 Support ”.
In case the test are negative uninstall the fix and restore the previous state of the Compute Node by running the following commands on the deployer node;
```
tux > sudo zypper install --force venv-openstack-nova-x86_64-OLD-VERSION
ardana > cd ~/scratch/ansible/next/ardana/ansible
ardana > ansible-playbook -i hosts/verb_hosts nova-upgrade.yml \
--limit=inputmodel-ccp-compute0001-mgmt
```
Make sure to replace OLD-VERSION with the version number you checked in the first step.