Baremetal QuickStart
Last updated
Last updated
Commands in this section will use the system package manager, and run with root privileges. It is recommended to use python virtual environments to install chi-in-a-box and kolla-ansible.
Install Python dependencies and
Ensure /usr/bin/python
links to python3
cc-ansible will install all of its own dependencies into a python virtualenv, located inside the chi-in-a-box git checkout directory. You'll need to do this before running other cc-ansible
subcommands.
Check out this repository:
Initialize your by running ./cc-ansible init
. This will place a default site configuration into ../site-config
. You can specify a different location by running
For example, running ./cc-ansible --site /opt/site-config init
should output:
This will set the CC_ANSIBLE_SITE
env var to point to this site configuration path for convenience. Consider adding it to your deploy user's login script. Example for bash:
Commands after this point assume that the environment variable is set.
To override, use ./cc-ansible --site <path/to/site> <command>
If you are only using two interfaces, you must do some additional configuration to avoid losing access during install (and other, hard to debug issues)
${CC_ANSIBLE_SITE}/inventory/hosts
Note If you used
./cc-ansible init
this may have been done automatically for you.
${CC_ANSIBLE_SITE}/inventory/host_vars/<hostname>
network_interface should be set to the name of the private interface (or bridge if only two interfaces) you chose
kolla_external_vip_interface should be set to the name of the public interface (or bridge if only two interfaces) you chose
${CC_ANSIBLE_SITE}/certificates/haproxy.pem
Provide a certificate matching the hostname, which must resolve to the chosen public IP.
The certificate must be placed in ${CC_ANSIBLE_SITE}/certificates/haproxy.pem
An HAProxy PEM file is a concatenation of the certificate, any intermediate certificates in the chain, and then the private key.
${CC_ANSIBLE_SITE}/defaults.yml
The following keys are mandatory for the install to complete. Set the values as appropriate to your setup.
If you haven't been provided a keystone_idp_client_id by your federated ID provider, disable it for now:
To give nodes internet access, at lease one internal and one external network must be enabled.
To enable bare metal provisioning, provide a vlan and subnet for ironic to use. This vlan should be included in the neutron on_demand_vlan_range
above.
Bootstrap your controller node by running ./cc-ansible bootstrap-servers
With the default configuration, it would be:
This will install Docker on your target node and put SELinux into permissive mode
Reboot if needed to apply SELinux changes
If you plan to run the provisioning tools as a non-root user, you will need to allow access to Docker. One easy way is to add the user to the docker
group, though this effectively gives the user root access. The deploy will install docker, but at this point you'll need to create the group manually.
Log out and back in, and check your group membership using:
kolla-ansible has a set of roles under prechecks
to ensure that the system configuration is consistent and avoids known edge cases. Run these via the command
For example, if the subnets configured in defaults.yml
do not match your interfaces, an error will be thrown here.
Similarly, kolla-ansible is not compatible with the service nscd
, and will require that it be disabled before succeeding.
All Chameleon services are packaged as Docker containers and they need to be downloaded to your host machine(s) as a first step. This will take a while depending on your connection.
The Chameleon Docker registry requires authentication. use the read-only password kaQBdG9PRwlpTzknnhfGmvPf
run the following command, and set the value for key docker_registry_password
Pull the container images.
Once the images are pulled, you can run the "deploy" phase, which sets up all the configuration for all the services and deploys them piece by piece.
Note: if you encounter errors and need to re-run the deploy step, which is expensive, you can skip parts you know have already succeeded. You can watch the Ansible output to see which "role" (service) it is updating. If you know a certain role has completed successfully, you can try skipping it on the next run with the
--skip-tags
option, e.g.--skip-tags keystone,nova
to skip the Keystone and Nova provisioning. You can persist these by uncommenting their lines inkolla-skip-tags
Once the deployment is complete, there should be a more or less functional OpenStack deployment that you can log in to. The admin credentials can be seen using ./cc-ansible view_passwords
under keystone
However, much of the bare metal functionality will not work, as there are a few special entities necessary, namely:
A provisioning network on its own VLAN, which Ironic must know about
Access on that VLAN to the Ironic TFTP server
A "baremetal" Nova flavor that is used to allow users to schedule bare metal deployments
Ironic deploy images available in Glance that hold the deployment ramdisk/kernel
A special "freepool" Nova aggregate used by Blazar to manage node reservations
All of these will be provisioned by running the post-deploy script:
After running post-deploy
, two new images will have been downloaded, and added to glance, named pxe_deploy_kernel
and pxe_deploy_ramdisk
.
Ironic needs to be configured to use these images to netboot nodes, and you'll need the UUIDs that glance assigned to them. Get them either from Horizon, under images, or by running openstack image show <name>
.
To set them as default, add the following to your defaults.yml
Then, run cc-ansible deploy --tags ironic
to deploy the change.
These will be used if not overridden for a specific node, which can be done via:
Run the following commands:
post-deploy
will create a file named admin-openrc.sh
in your site-config directory. This file shouldn't be checked into source control, as it contains secrets.
To use it, run source $CC_ANSIBLE_SITE/admin-openrc.sh
This will set a variety of environment variables, all prefixed with OS_
Verify that it works by running openstack token issue
It's recommended to use individual user accounts to log in, rather than the built-in superadmin account. You can users to the admin project as follows:
Get their UUID from openstack user show <username>
or look for them in openstack user list
. They will need to have logged into the site at least once to appear here.
Add them to the openstack project. openstack role add --user <user_uuid> --project openstack admin
Follow the steps in Hardware management to enroll nodes in your testbed.
Edit the of your site configuration to include the hostname of the node you are installing to. By default, the controller node can also be network, monitoring, and storage. It should look like this:
Update the "" file for your host to include the correct names of the network interfaces you want to use.
currently