36 Troubleshooting the Installation #

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.

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:

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

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.

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

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

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

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

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.

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.

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 Section 6.14, “Networks”.

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