Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
Applies to SUSE OpenStack Cloud 8

23 Troubleshooting the Installation Edit source

We have gathered some of the common issues that occur during installation and organized them by when they occur during the installation. These sections will coincide with the steps labeled in the installation instructions.

23.1 Issues during Cloud Lifecycle Manager Setup Edit source

Issue: Running the ardana-init.bash script when configuring your Cloud Lifecycle Manager does not completeEdit source

Part of what the ardana-init.bash script does is install Git. So if your DNS server(s) is/are not specified in your /etc/resolv.conf file, is not valid, or is not functioning properly on your Cloud Lifecycle Manager, it will not be able to complete.

To resolve this issue, double check your nameserver in your /etc/resolv.conf file and then re-run the script.

23.2 Issues while Updating Configuration Files Edit source

Configuration Processor Fails Due to Wrong yml FormatEdit source

If you receive the error below when running the configuration processor then you may have a formatting error:

TASK: [fail msg="Configuration processor run failed, see log output above for
details"]

First you should check the Ansible log in the location below for more details on which yml file in your input model has the error:

~/.ansible/ansible.log

Check the configuration file to locate and fix the error, keeping in mind the following tips below.

Check your files to ensure that they do not contain the following:

  • Non-ascii characters

  • Unneeded spaces

Once you have fixed the formatting error in your files, commit the changes with these steps:

  1. Commit your changes to Git:

    cd ~/openstack/ardana/ansible
    git add -A
    git commit -m "My config or other commit message"
  2. Re-run the configuration processor playbook and confirm the error is not received again.

Configuration processor fails with provider network OCTAVIA-MGMT-NET errorEdit source

If you receive the error below when running the configuration processor then you have not correctly configured your VLAN settings for Octavia.

################################################################################,
# The configuration processor failed.
#   config-data-2.0           ERR: Provider network OCTAVIA-MGMT-NET host_routes:
# destination '192.168.10.0/24' is not defined as a Network in the input model.
# Add 'external: True' to this host_route if this is for an external network.
################################################################################

To resolve the issue, ensure that your settings in ~/openstack/my_cloud/definition/data/neutron/neutron_config.yml are correct for the VLAN setup for Octavia.

Changes Made to your Configuration FilesEdit source

If you have made corrections to your configuration files and need to re-run the Configuration Processor, the only thing you need to do is commit your changes to your local Git repository:

cd ~/openstack/ardana/ansible
git add -A
git commit -m "commit message"

You can then re-run the configuration processor:

cd ~/openstack/ardana/ansible
ansible-playbook -i hosts/localhost config-processor-run.yml
Configuration Processor Fails Because Encryption Key Does Not Meet RequirementsEdit source

If you choose to set an encryption password when running the configuration processor, you may receive the following error if the chosen password does not meet the complexity requirements:

################################################################################
# The configuration processor failed.
#   encryption-key ERR: The Encryption Key does not meet the following requirement(s):
#       The Encryption Key must be at least 12 characters
#       The Encryption Key must contain at least 3 of following classes of characters:
#                           Uppercase Letters, Lowercase Letters, Digits, Punctuation
################################################################################

If you receive the above error, run the configuration processor again and select a password that meets the complexity requirements detailed in the error message:

cd ~/openstack/ardana/ansible
ansible-playbook -i hosts/localhost config-processor-run.yml

23.3 Issues while Deploying the Cloud Edit source

Issue: If the site.yml playbook fails, you can query the log for the reasonEdit source

Ansible is good about outputting the errors into the command line output, however if you would like to view the full log for any reason the location is:

~/.ansible/ansible.log

This log is updated real time as you run Ansible playbooks.

Tip
Tip

Use grep to parse through the log. Usage: grep <text> ~/.ansible/ansible.log

Issue: How to Wipe the Disks of your MachinesEdit source

If you have re-run the site.yml playbook, you may need to wipe the disks of your nodes

You should run the wipe_disks.yml playbook only after re-running the bm-reimage.yml playbook but before you re-run the site.yml playbook.

cd ~/scratch/ansible/next/ardana/ansible
ansible-playbook -i hosts/verb_hosts wipe_disks.yml

The playbook will show you the disks to be wiped in the output and allow you to confirm that you want to complete this action or abort it if you do not want to proceed. You can optionally use the --limit <NODE_NAME> switch on this playbook to restrict it to specific nodes. This action will not affect the OS partitions on the servers.

If you receive an error stating that osconfig has already run on your nodes then you will need to remove the /etc/ardana/osconfig-ran file on each of the nodes you want to wipe with this command:

sudo rm /etc/ardana/osconfig-ran

That will clear this flag and allow the disk to be wiped.

Issue: Freezer installation fails if an independent network is used for the External_APIEdit source

The Freezer installation fails if an independent network is used for the External_API. If you intend to deploy the External API on an independent network, the following changes need to be made:

In roles/freezer-agent/defaults/main.yml add the following line:

backup_freezer_api_url: "{{ FRE_API | item('advertises.vips.private[0].url', default=' ') }}"

In roles/freezer-agent/templates/backup.osrc.j2 add the following line:

export OS_FREEZER_URL={{ backup_freezer_api_url }}
Error Received if Root Logical Volume is Too SmallEdit source

When running the site.yml playbook, you may receive a message that includes the error below if your root logical volume is too small. This error needs to be parsed out and resolved.

2015-09-29 15:54:03,022 p=26345 u=stack | stderr: New size given (7128 extents)
not larger than existing size (7629 extents)

The error message may also reference the root volume:

"name": "root", "size": "10%"

The problem here is that the root logical volume, as specified in the disks_controller.yml file, is set to 10% of the overall physical volume and this value is too small.

To resolve this issue you need to ensure that the percentage is set properly for the size of your logical-volume. The default values in the configuration files is based on a 500 GB disk, so if your logical volumes are smaller you may need to increase the percentage so there is enough room.

Multiple Keystone Failures Received during site.ymlEdit source

If you receive the Keystone error below during your site.yml run then follow these steps:

TASK: [OPS-MON | _keystone_conf | Create Ops Console service in Keystone] *****
failed:
[...]
msg: An unexpected error prevented the server from fulfilling your request.
(HTTP 500) (Request-ID: req-23a09c72-5991-4685-b09f-df242028d742), failed

FATAL: all hosts have already failed -- aborting

The most likely cause of this error is that the virtual IP address is having issues and the Keystone API communication through the virtual IP address is not working properly. You will want to check the Keystone log on the controller where you will likely see authorization failure errors.

Verify that your virtual IP address is active and listening on the proper port on all of your controllers using this command:

netstat -tplan | grep 35357

Ensure that your Cloud Lifecycle Manager did not pick the wrong (unusable) IP address from the list of IP addresses assigned to your Management network.

The Cloud Lifecycle Manager will take the first available IP address after the gateway-ip defined in your ~/openstack/my_cloud/definition/data/networks.yml file. This IP will be used as the virtual IP address for that particular network. If this IP address is used and reserved for another purpose outside of your SUSE OpenStack Cloud deployment then you will receive the error above.

To resolve this issue we recommend that you utilize the start-address and possibly the end-address (if needed) options in your networks.yml file to further define which IP addresses you want your cloud deployment to use. For more information, see Book “Planning an Installation with Cloud Lifecycle Manager”, Chapter 6 “Configuration Objects”, Section 6.14 “Networks”.

After you have made changes to your networks.yml file, follow these steps to commit the changes:

  1. Ensuring that you stay within the ~/openstack directory, commit the changes you just made:

    cd ~/openstack
    git commit -a -m "commit message"
  2. Run the configuration processor:

    cd ~/openstack/ardana/ansible
    ansible-playbook -i hosts/localhost config-processor-run.yml
  3. Update your deployment directory:

    cd ~/openstack/ardana/ansible
    ansible-playbook -i hosts/localhost ready-deployment.yml
  4. Re-run the site.yml playbook:

    cd ~/scratch/ansible/next/ardana/ansible
    ansible-playbook -i hosts/verb_hosts site.yml
Print this page