![Jesse Pretorius](/assets/img/avatar_default.png)
In order to radically simplify how we prepare the service venvs, we use a common role to do the wheel builds and the venv preparation. This makes the process far simpler to understand, because the role does its own building and installing. It also reduces the code maintenance burden, because instead of duplicating the build processes in the repo_build role and the service role - we only have it all done in a single place. Given that the role now handles everything, and has sensible defaults, we can remove the *_venv_tag and *_venv_download_url in group_vars. This is by no means the final stop in the simplification process, but it is a step forward. The will be work to follow which: 1. Changes how we define the versions of each service we wish to install. Currently this requires the use of the py_pkgs plugin, but we'd like to eliminate that to simplify the mechanism to something more intuitive. 2. Changes how we set the pip install arguments for the venv build. Right now the repo_build consolidates all constraints into a single set. That code is complex, difficult to understand and prohibits multi-series deployments. 3. Changes how we configure pip. Given that we no longer do pip installs onto the host, and only use venvs, we do not need to place pip.conf in a global location. We can explore other options, including perhaps not placing pip.conf at all. 4. Removes the repo_build process entirely. Once the roles are doing everything that's required, the repo_build process will be redundant and can be removed. Depends-On: https://review.openstack.org/557039 Depends-On: https://review.openstack.org/557041 Depends-On: https://review.openstack.org/557042 Depends-On: https://review.openstack.org/557043 Depends-On: https://review.openstack.org/557047 Depends-On: https://review.openstack.org/557049 Depends-On: https://review.openstack.org/557050 Depends-On: https://review.openstack.org/557052 Depends-On: https://review.openstack.org/557053 Depends-On: https://review.openstack.org/557055 Depends-On: https://review.openstack.org/557059 Depends-On: https://review.openstack.org/557061 Depends-On: https://review.openstack.org/567692 Depends-On: https://review.openstack.org/599238 Depends-On: https://review.openstack.org/599240 Depends-On: https://review.openstack.org/599244 Depends-On: https://review.openstack.org/599247 Depends-On: https://review.openstack.org/599256 Depends-On: https://review.openstack.org/599434 Depends-On: https://review.openstack.org/599437 Change-Id: Ic31bd1c9f1c3eea61af50210d93aa96f9c797d92
Team and repository tags
OpenStack-Ansible
OpenStack-Ansible is an official OpenStack project which aims to deploy production environments from source in a way that makes it scalable while also being simple to operate, upgrade, and grow.
For an overview of the mission, repositories and related Wiki home page, please see the formal Home Page for the project.
For those looking to test OpenStack-Ansible using an All-In-One (AIO) build, please see the Quick Start guide.
For more detailed Installation and Operator documentation, please see the Deployment Guide.
If OpenStack-Ansible is missing something you'd like to see included, then we encourage you to see the Developer Documentation for more details on how you can get involved.
Developers wishing to work on the OpenStack-Ansible project should always base their work on the latest code, available from the master GIT repository at Source.
If you have some questions, or would like some assistance with
achieving your goals, then please feel free to reach out to us on the OpenStack Mailing Lists
(particularly openstack-operators or openstack-dev) or on IRC in
#openstack-ansible
on the freenode network.
OpenStack-Ansible Roles
OpenStack-Ansible offers separate role repositories for each individual role that OpenStack-Ansible supports. For individual role configuration options, see the Role Documentation.
An individual role's source code can be found at: https://git.openstack.org/cgit/openstack/openstack-ansible-<ROLENAME>.