Ocata Series (3.0.0 - 3.0.x) Release Notes


New Features

  • Allow consuming upper_constraints_file from an env var UPPER_CONSTRAINTS_FILE. This will be specially useful for OpenStack CI, where this var is defined on each job run, pointing to the right requirements file depending on branch.

Bug Fixes

  • The CI test playbook previously looked for the requirements respository in /opt/git/openstack/. This has been changed to use the WORKSPACE environment variable when being executed.


During the Ocata cycle, a number of improvements have been made to bifrost to improve the managability and longevity of a bifrost installation. Coupled with a number of fixes, and improvements, users upgrading should take the time to read the entire release notes. A few highlights are below:

  • Bifrost now installs and utilizes Ansible 2.1 by default from PyPI.
  • Ironic’s default of modifying a pre-existing ironic.conf upon the installation being re-executed, has been changed to a utilize a template file.
  • Bifrost supports generating and reading from a os-client-config clouds.yaml file for obtaining credentials.
  • Bifrost can now leverage authentiation, as well as install and configure keystone if requested by the installer.
  • As a number of in-tree drivers in ironic were removed this past cycle, due to lack of third-party CI, support has been added to enable installation of the staging drivers repository.

New Features

  • Allow user to insert private SSH key for ironic user. This is useful for ansible deploy driver and another ssh based drivers. The private key can be specified as path to local file in ssh_private_key_path variable, or as string in ssh_private_key.
  • Allow install Ironic on remote server. Added group ‘target’ to inventory, which is same as localhost by default. For install ironic remotely, address and ssh credentials should be configured in playbooks/inventory/target file.
  • Bifrost has been updated to utilize Ansible 2.1’s stable branch for the version of ansible installed.
  • Bifrost now prefers to use a system with Ansible already installed. When this is the case, execution of the env-setup.sh script is not required as it is geared for development and testing use of bifrost.

    In order to use the playbooks on a system with Ansible already installed, the library requirements must be installed prior to playbook execution:

    pip install -r requirements.txt

    Administrative privileges may be required if the packages must be installed system wide.

  • The environment setup script will now attempt to install bifrost from PyPI instead of using a stable branch. This is to address stability issues with Ansible stable branches.

    If not requested to be installed into virtualenv, Ansible will be installed into user’s ~/.local directory to not clobber possibly existing system installation. To use such installed Ansible, modifications of $PATH environment variable might be required to include ~/.local/bin path.

    Some backwards compatibility is provided via the use of the ANSIBLE_GIT_BRANCH variable, where a user can define stable-X.Y and the latest available version in that series will be installed. To install the Ansible 2.1 series as part of the env-setup script, execute env ANSIBLE_GIT_BRANCH="stable-2.1" scripts/env-setup.

    Similarly, ANSIBLE_PIP_VERSION can be utilized to specify the exact version, or range of version desired. Example:


  • Allows to choose to leverage authentication with roles that interact with ironic services via ansible modules. This is limited to sessions that obtain authentication information via os-client-config. The role defaults ultimately remain unchanged and default to noauth mode. More information on os-client-config can be found at http://docs.openstack.org/developer/os-client-config/
  • Bifrost now has a role that can create a clouds.yaml file for os-client-config based client auto-configuration.
  • The functionality to create a service account and default user account to bifrost has been added. This is controlled by the enable_keystone parameter as well a keystone and ironic data structure that contains all required parameters. Please consult the bifrost-ironic-install/defaults/main.yml file for more details.
  • Previously bifrost deployments on RedHat/Suse systems had to be performed with selinux at least in permissive mode. This patch adds the necessary policies to allow the components to operate with selinux in enforcing mode.
  • bifrost now supports dnf as package manager on RedHat-based distros. It tries to use it by default and falls back to yum when dnf is not available.
  • Discovery of nodes via the ironic-inspector is now enabled by default. If you wish to disable this, set enable_inspector_discovery to false and re-execute the installation playbook.
  • Inspector is now installed and enabled by default. This changes default value for the enable_inspector variable from false to true.
  • Functionality to configure the ironic-inspector to utilize keystone, utilizing the base enable_keystone boolean parameter.
  • An ansible role enabling the installation of keystone has been added in preparation for the addition of keystone support to bifrost.
  • The bifrost-keystone-client-config role can now write a clouds.yaml file with several clouds settings. It starts to accept a single compound variable clouds that must contain a dictionary describing key:value pairs in the format of <cloud-name>:<dict-of-cloud-settings>. The previous way of passing config_* vars to the role is supported for backward compatibility but is deprecated and should be expected to be removed in Pike.

    In addition to previous bifrost cloud, the default install.yaml playbook now also writes bifrost-admin cloud settings that contain Keystone admin credentials so that when installed, the Keystone service is fully usable right away (users/projects etc can be managed).

  • The capability for Bifrost to read directly from the os-client-config data has been added. While shade can do this for us to a degree, bifrost also allows a user to directly choose the server which they are connecting to via the ironic_url parameter. Instead of duplicate code and retool, if no global auth parameter is detected, the authentication parameters from the os_client_config module is utilized to set the parameters.
  • An optional parameter has been added to the roles that interact with ironic that defines a cloud_name. This cloud name is utilized by the roles to determine the entry from os-client-config to utilize.
  • Add support of remote logging. This feature allows to send logs from local syslog server and not collects logs from services on baremetal nodes. To collect from the actual running nodes requires configuration injected into each deployed host. Syslog server address and port can be specified in options remote_syslog_server and remote_syslog_port respectively.
  • Ironic-Staging-Drivers can now be installed. These are drivers that are not included in the ironic repo, and provide additional hardware support for ironic. More information about the drivers can be found at Ironic-Staging-Drivers To install the staging drivers set staging_drivers_include to true. The default value is false.
  • Ironic.conf is templated and only sets required options now, as opposed to editing the sample configuration of Ironic.

Known Issues

  • If installing bifrost in a virtualenv (venv) and running playbooks against localhost, you must install the basic python requirements on a system-wide level due to the operating behavior of Ansible.
  • Users wishing to utilize authentication without leveraging os-client-config, will need to manually update the playbooks in order to set the appropriate module settings.
  • Bifrost now has a role that can create a clouds.yaml file for os-client-config based client auto-configuration. This file overwrites the default file for the user executing bifrost, located at ~/.config/openstack/clouds.yaml. It is recommended that users execute bifrost’s installation via a service account.
  • The addition of support for os-client-config does not allow a user to choose their cloud directly. Only the first entry returned is utilized.
  • Log entries where authentication data is read and stored have been masked with the no_log parameter. Troubleshooting non-standard authentication configurations may require modifying the playbooks so users can debug their input OR pass data directly in a different way.

Upgrade Notes

  • Bifrost has been changed to utilize Ansible 2.1 by default. Should a deployment encounter issues with Ansible, they may wish to check/update their version of Ansible, or re-execute the env-setup.sh script.
  • Bifrost no longer supports installing ironic AMT drivers when PXE drivers are enabled (which is the default) due to AMT drivers having been removed from ironic in Ocata release.
  • Upon installation, bifrost will replace the installed ironic.conf file with a template generated file. Custom setting changes to that file, which were previously retained, will now be lost upon re-installation.

Deprecation Notes

  • The ANSIBLE_INSTALL_ROOT variable has been deprecated and is used only to raise a warning for third party scripts.
  • The ANSIBLE_FROM_PYPI variable no longer has any effect, as Ansible is always installed from PyPI now.
  • The node_network_info parameter has been deperecated in favor of the node_network_data parameter as the related configuration drive network_info.json file was misnamed originally, and should have been named network_data.json. Support for the node_network_info, and the continued write-out of the network_info.json file in configuration drives will be removed in the Queens cycle.
  • The ironic_auth_strategy setting is deprecated and will be removed in Pike. The setting has no effect if the enable_keystone setting is present and set to true.
  • The inspector_auth setting is deprecated and will be removed in Pike. The setting has no effect if the enable_keystone setting is present and set to true.
  • Passing config_* variables defining credentials for bifrost cloud to the bifrost-keystone-client-config role has been deprecated, and will be removed in the Pike cycle. Instead a single compound variable named clouds defining sets of settings to be written to clouds.yaml should be passed to that role.

Bug Fixes

  • Due to breaking change in the stable branch tags utilized with Ansible, bifrost now utilizes installation of Ansible from PyPI.
  • When support for passing configuration drive data to the nodes was originally created, the file was accidently named incorrectly as network_info.json. The correct filename is network_data.json. Both files will now be written until support for writing network_info.json is removed in the Queens cycle.
  • Added dhcp configuration tasks to inspection role. In case when inventory_dhcp is enabled and node is not deployed yet, inspection is not working because dnsmasq ignores requests from unknown address. This fix introduces tasks which configures dhcp before inspection.
  • Some users have encountered issues with introspection periodically timing out for systems. As a result, we have added a new parameter inspection_wait_timeout that is now defaulted to 1800 seconds.

Other Notes

  • By default, the installation process now downloads iPXE binaries from ipxe.org upon re-installation. Previously, the download was not set to be forced, and thus would be skipped if the file was already present.
  • In the past, the sample config in Ironic may have set some boilerplate that Bifrost took advantage of. But now that config is entirely made up of comments, and so this change does not change much except stripping out all of those comments and leaving just the required content in ironic.conf to use Ironic with Bifrost.