Although AIO builds aren’t recommended for large production deployments, they’re great for smaller proof-of-concept deployments.
Building an AIO
There are three steps to running an AIO build, with an optional first step should you need to customize your build:
- Configuration (this step is optional)
- Install and bootstrap Ansible
- Initial host bootstrap
- Run playbooks
When building an AIO on a new server, it is recommended that all system packages are upgraded and then reboot into the new kernel:
Note
Execute the following commands and scripts as the root user.
Note Arnaud pour Ubuntu dans ProxMox :
# sudo add-apt-repository universe
# sudo apt install qemu-guest-agent
# Ubuntu
# apt-get dist-upgrade
# reboot
Note : If you are installing with limited connectivity, please review the
Installing with limited connectivity appendix in the
Deployment Guide before proceeding.
Start by cloning the OpenStack-Ansible repository and changing into the repository root directory:
# git clone https://git.openstack.org/openstack/openstack-ansible \
/opt/openstack-ansible
# cd /opt/openstack-ansible
Next switch the applicable branch/tag to be deployed from. Note that deploying from the head of a branch may result in an unstable build due to changes in flight and upstream OpenStack changes. For a test (for example, not a development) build it is usually best to checkout the latest tagged version.
# # List all existing tags.
# git tag -l
# # Checkout the stable branch and find just the latest tag
# git checkout master
# git describe --abbrev=0 --tags
# # Checkout the latest tag from either method of retrieving the tag.
# git checkout master
Note
The Stein release is only compatible with Ubuntu 16.04 (Xenial Xerus), Ubuntu 18.04 (Bionic Beaver) Centos 7 and openSUSE Leap 42.X.
By default the scripts deploy all OpenStack services with sensible defaults for the purpose of a gate check, development or testing system.
Review the bootstrap-host role defaults file to see various configuration options. Deployers have the option to change how the host is bootstrapped. This is useful when you wish the AIO to make use of a secondary data disk, or when using this role to bootstrap a multi-node development environment.
The bootstrap script is pre-set to pass the environment variable BOOTSTRAP_OPTS
as an additional option to the bootstrap process. For example, if you wish to set the bootstrap to re-partition a specific secondary storage device (/dev/sdb
), which will erase all of the data on the device, then execute:
# export BOOTSTRAP_OPTS="bootstrap_host_data_disk_device=sdb"
By default the filesystem type will be set to ext4, if you want another type of filesystem to be used, just use something similar to the following:
# export BOOTSTRAP_OPTS="bootstrap_host_data_disk_device=sdb bootstrap_host_data_disk_fs_type=xfs"
Additional options may be implemented by simply concatenating them with a space between each set of options, for example:
# export BOOTSTRAP_OPTS="bootstrap_host_data_disk_device=sdb"
# export BOOTSTRAP_OPTS="${BOOTSTRAP_OPTS} bootstrap_host_ubuntu_repo=http://mymirror.example.com/ubuntu"
You may wish to change the role fetch mode. Options are galaxy
and git-clone
. The default for this option is galaxy
.
- options:
-
galaxy: |
Resolve all role dependencies using the ansible-galaxy resolver |
git-clone: |
Clone all of the role dependencies using native git |
- Notes:
- When doing role development it may be useful to set
ANSIBLE_ROLE_FETCH_MODE
to git-clone
. This will provide you the ability to develop roles within the environment by modifying, patching, or committing changes using an intact git tree while the galaxy
option scrubs the .git
directory when it resolves a dependency.
$ export ANSIBLE_ROLE_FETCH_MODE=git-clone
The next step is to bootstrap Ansible and the Ansible roles for the development environment. Deployers can customize roles by adding variables to override the defaults in each role (see Overriding default configuration). Run the following to bootstrap Ansible:
# scripts/bootstrap-ansible.sh
- Notes:
-
You might encounter an error while running the Ansible bootstrap script when building some of the Python extensions (like pycrypto) which says:
configure: error: cannot run C compiled programs.
The reason of this failure might be resulting from a noexec mount flag used for the filesystem associated with /tmp which you can check by running the following command:
# mount | grep $(df /tmp | tail -n +2 | awk '{print $1}') | grep noexec
If this is the case you can specify an alternate path which does not have this mount option set:
# TMPDIR=/var/tmp scripts/bootstrap-ansible.sh
In order for all the services to run, the host must be prepared with the appropriate disks partitioning, packages, network configuration and configurations for the OpenStack Deployment.
For the default AIO scenario, this preparation is completed by executing:
# scripts/bootstrap-aio.sh
If you wish to use a different scenario, for example, the Ceph scenario, execute the following:
# export SCENARIO='ceph'
# scripts/bootstrap-aio.sh
Tested Scenarios
To add OpenStack Services over and above the bootstrap-aio default services for the applicable scenario, copy the conf.d
files with the .aio
file extension into /etc/openstack_deploy
and rename then to .yml
files. For example, in order to enable the OpenStack Telemetry services, execute the following:
# cd /opt/openstack-ansible/
# cp etc/openstack_deploy/conf.d/{aodh,gnocchi,ceilometer}.yml.aio /etc/openstack_deploy/conf.d/
# for f in $(ls -1 /etc/openstack_deploy/conf.d/*.aio); do mv -v ${f} ${f%.*}; done
To add any global overrides, over and above the defaults for the applicable scenario, edit/etc/openstack_deploy/user_variables.yml
. See the Deployment Guide for more details.
Finally, run the playbooks by executing:
# cd /opt/openstack-ansible/playbooks
# openstack-ansible setup-hosts.yml
# openstack-ansible setup-infrastructure.yml
# openstack-ansible setup-openstack.yml
The installation process will take a while to complete, but here are some general estimates:
- Bare metal systems with SSD storage: ~ 30-50 minutes
- Virtual machines with SSD storage: ~ 45-60 minutes
- Systems with traditional hard disks: ~ 90-120 minutes
Once the playbooks have fully executed, it is possible to experiment with various settings changes in /etc/openstack_deploy/user_variables.yml
and only run individual playbooks. For example, to run the playbook for the Keystone service, execute:
# cd /opt/openstack-ansible/playbooks
# openstack-ansible os-keystone-install.yml