Train Series Release Notes

18.0.0.0b1-82

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.

Deprecation Notes

  • The repo build process no longer builds packaged venvs. Instead, the venvs are created on the target hosts as the install process for each service needs to. This opens up the opportunity for roles to be capable of creating multiple venvs, and for any role to create venvs - neither of these options were possible in previous releases.

    The following variables therefore have been removed.

    • repo_build_venv_selective

    • repo_build_venv_rebuild

    • repo_build_venv_timeout

    • repo_build_concurrency

    • repo_build_venv_build_dir

    • repo_build_venv_dir

    • repo_build_venv_pip_install_options

    • repo_build_venv_command_options

    • repo_venv_default_pip_packages

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 tag repo-build-wheels completes the wheel build process. The tag repo-build-venvs completes the venv build process. Finally, the tag repo-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 variable repo_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 to present.

  • 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 to no.

  • 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 to no.

  • 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 variable repo_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 to present.

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 to true.

  • 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 to yes.

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 setting repo_build_uca_enable to False.

Bug Fixes