Rocky Series Release Notes¶
18.0.0.0b1-49¶
New Features¶
The option
repo_venv_default_pip_packages
has been added which will allow deployers to insert any packages into a service venv as needed. The option expects a list of strings which are valid python package names as found on PYPI.
16.0.0.0b3¶
Upgrade Notes¶
The entire repo build process is now idempotent. From now on when the repo build is re-run, it will only fetch updated git repositories and rebuild the wheels/venvs if the requirements have changed, or a new release is being deployed.
The git clone part of the repo build process now only happens when the requirements change. A git reclone can be forced by using the boolean variable
repo_build_git_reclone
.
The python wheel build process now only happens when requirements change. A wheel rebuild may be forced by using the boolean variable
repo_build_wheel_rebuild
.
The python venv build process now only happens when requirements change. A venv rebuild may be forced by using the boolean variable
repo_build_venv_rebuild
.
The repo build process now only has the following tags, providing a clear path for each deliverable. The tag
repo-build-install
completes the installation of required packages. The tagrepo-build-wheels
completes the wheel build process. The tagrepo-build-venvs
completes the venv build process. Finally, the tagrepo-build-index
completes the manifest preparation and indexing of the os-releases and links folders.
Deprecation Notes¶
The variable
repo_build_pip_extra_index
has been removed. The replacement list variablerepo_build_pip_extra_indexes
should be used instead.
16.0.0.0b1¶
New Features¶
The repo server file system structure has been updated to allow for multiple Operating systems running multiple architectures to be run at the same time and served from a single server without impacting pools, venvs, wheel archives, and manifests. The new structure follows the following pattern $RELEASE/$OS_TYPE-$ARCH and has been applied to os-releases, venvs, and pools.
Other Notes¶
From now on, external repo management (in use for RDO/UCA for example) will be done inside the pip-install role, not in the repo_build role.
15.0.0.0rc1¶
New Features¶
The filename of the apt source for the ubuntu cloud archive can now be defined with the variable
uca_apt_source_list_filename
.
14.0.0.0rc1¶
Bug Fixes¶
The pip_install_options variable is now honored during repo building. This variable allows deployers to specify trusted CA certificates by setting the variable to “–cert /etc/ssl/certs/ca-certificates.crt”
The repo_build play now correctly evaluates environment variables configured in /etc/environment. This enables deployments in an environment with http proxies.
14.0.0.0b3¶
New Features¶
The repo build process is now able to support building and synchronizing artifacts for multiple CPU architectures. Build artifacts are now tagged with the appropriate CPU architecture by default, and synchronization of build artifacts from secondary, architecture-specific repo servers back to the primary repo server is supported.
The repo_build role now supports the ability to configure whether apt/yum tasks install the latest available package, or just ensure that the package is present. The default action is to ensure that the latest package is present. The action taken may be changed to only ensure that the package is present by setting
repo_build_package_state
topresent
.
The repo build process now selectively clones git repositories based on whether each OpenStack service group has any hosts in it. If there are no hosts in the group, the git repo for the service will not be cloned. This behaviour can be optionally changed to force all git repositories to be cloned by setting
repo_build_git_selective
tono
.
The repo build process now selectively builds python packages based on whether each OpenStack service group has any hosts in it. If there are no hosts in the group, the list of python packages for the service will not be built. This behaviour can be optionally changed to force all python packages to be built by setting
repo_build_wheel_selective
tono
.
The
repo_build
role now provides the ability to override the upper-constraints applied which are sourced from OpenStack and from the global-requirements-pins.txt file. The variablerepo_build_upper_constraints_overrides
can be populated with a list of upper constraints. This list will take the highest precedence in the constraints process, with the exception of the pins set in the git source SHAs.
Upgrade Notes¶
The repo_build role always checks whether the latest package is installed when executed. If a deployer wishes to change the check to only validate the presence of the package, the option
repo_build_package_state
should be set topresent
.
14.0.0.0b2¶
New Features¶
The repo build process is now able to make use of a pre-staged git cache. If the
/var/www/repo/openstackgit
folder on the repo server is found to contain existing git clones then they will be updated if they do not already contain the required SHA for the build.
The repo build process now has the ability to store the pip sources within the build archive. This ability is useful when deploying environments that are “multi-architecture”, “multi-distro”, or “multi-interpreter” where specific pre-build wheels may not be enough to support all of the deployment. To enable the ability to store the python source code within a given release, set the new option
repo_build_store_pip_sources
totrue
.
The repo build process now selectively builds venvs based on whether each OpenStack service group has any hosts in it. If there are no hosts in the group, the venv will not be built. This behaviour can be optionally changed to force all venvs to be built by setting
repo_build_venv_selective
toyes
.
Upgrade Notes¶
The
repo_build_apt_packages
variable has been renamed.repo_build_distro_packages
should be used instead to override packages required to build Python wheels and venvs.
The
repo_build
role now makes use of Ubuntu Cloud Archive by default. This can be disabled by settingrepo_build_uca_enable
toFalse
.
Bug Fixes¶
The
repo_build
role now correctly applies OpenStack requirements upper-constraints when building Python wheels. This resolves https://bugs.launchpad.net/openstack-ansible/+bug/1605846