Installing with Cloud Lifecycle Manager
- Installation Overview
- I Pre-Installation
- II Cloud Installation
- 7 Overview
- 8 Preparing for Stand-Alone Deployment
- 9 Installing with the Install UI
- 10 Using Git for Configuration Management
- 11 Installing a Stand-Alone Cloud Lifecycle Manager
- 12 Installing Mid-scale and Entry-scale KVM
- 13 DNS Service Installation Overview
- 14 Magnum Overview
- 15 Installing ESX Computes and OVSvAPP
- 16 Integrating NSX for vSphere
- 17 Installing Baremetal (Ironic)
- 18 Installation for HPE Helion OpenStack Entry-scale Cloud with Swift Only
- 19 Installing SLES Compute
- 20 Installing Manila and Creating Manila Shares
- 21 Installing SUSE CaaS Platform Heat Templates
- 22 Installing RHEL Compute
- 23 Integrations
- 24 Troubleshooting the Installation
- 25 Troubleshooting the ESX
- III Post-Installation
- 34 Support
34 Support
Find solutions for common pitfalls and technical details for requesting HPE Helion OpenStack support.
34.1 FAQ #
Node Deployment
- 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.j2with an editor and addself_update=0to the line starting withlinuxefi. 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.j2If you need to reenable the installer self-update, remove
self_update=0and commit the changes.
34.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, HPE Helion OpenStack 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
http://documentation.suse.com/sles-12/book_sle_admin/data/cha_adm_support.html.
34.2.1 Applying PTFs (Program Temporary Fixes) Provided in Support Contract #
Under certain circumstances, PTFs may be provided RPM packages. To make them available on all nodes in your cloud, proceed as follows. (If you prefer to test them first on a single node, see Section 34.2.2, “ Testing PTFs (Program Temporary Fixes) on a Single Node ”.)
Download the packages from the location indicated by your support provider 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/
-
“noarch” packages (
Create or update the repository metadata:
ardana >createrepo-cloud-ptfTo 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
34.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, or 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 34.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_64Install the PTF on the deployer node:
tux >sudo zypper up ./venv-openstack-nova-x86_64-ptf.rpmThis 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_64This 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/ansibleardana >ansible-playbook -i hosts/verb_hosts nova-upgrade.yml \ --limit=inputmodel-ccp-compute0001-mgmt --list-hostsIf 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-mgmtIf your tests are positive, install the PTF on all nodes as described in Section 34.2.1, “ Applying PTFs (Program Temporary Fixes) Provided in Support Contract ”.
If the tests 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-VERSIONardana >cd ~/scratch/ansible/next/ardana/ansibleardana >ansible-playbook -i hosts/verb_hosts nova-upgrade.yml \ --limit=inputmodel-ccp-compute0001-mgmtMake sure to replace OLD-VERSION with the version number you checked in the first step.