Liberty Release

date:

2015-09-08 08:30

tags:

liberty, update

Update the various playbooks and roles in the master branch with the changes necessary to implement a fully functional and updated Liberty deployment.

Initial work will be based on the Liberty RC tags in each of the OpenStack projects since Liberty is not yet officially released.

Problem description

While the master branch has been tracking Liberty code for some time, none of the configuration files have been updated to match the upstream changes in order to handle deprecation, different default values, etc.

Proposed change

  1. Each template/file carried in-tree will need to be reviewed and revised according to the new defaults and other adjustments in each OpenStack project.

  2. Each service will need to be inspected for changes in how deployments and upgrades are handled, and the role tasks adjusted accordingly.

  3. Any other changes to each service will need to be inspected and adjustments to the roles must be made accordingly.

  4. In a final test, fatal_deprecations should be set to True for all the services to validate that all deprecated configurations have been removed or replaced.

The approach to dealing with differences (eg changed defaults for a particular setting) will be to use the Liberty value where possible. Deployers who are upgrading from Kilo may use the config_overrides to implement overrides for any configurations that they wish to keep at the previous values.

Examples of configs impacted (these will differ depending on the service being worked on):

/etc/<servicename>/<servicename>.conf
/etc/<servicename>/<servicename>-api-paste.ini
/etc/<servicename>/policy.json
/etc/<servicename>/<servicename>-<agentname>.ini

Alternatives

We could, wherever needed, preserve Kilo settings rather than taking forward the Liberty settings. This is potentially easier on users in an upgrade scenario, but does mean that new users deploying Liberty would get an already out of date deployment. It also means that we miss an opportunity to implement best practices deployments, instead sticking on old, less relevant, values.

Playbook impact

There will be no impact on the playbooks. These changes are on the dependency and role level which only impact the configuration files and role options.

Upgrade impact

This change will impact upgrades, but upgrades are specifically out of scope and will be addressed separately in https://blueprints.launchpad.net/openstack-ansible/+spec/liberty-upgrade-path

The focus for this spec will be for new deployments only.

Security impact

Security testing and improvements are specifically out of scope. Testing for security changes and improvements can be done after the release and implemented in subsequent patches.

Performance impact

Performance testing and improvements are specifically out of scope. Testing for performance changes and improvements can be done after the release and implemented in subsequent patches.

End user impact

N/A

Deployer impact

Impacts must be noted in the commit messages for each change.

Developer impact

This change is to allow development of a production grade Liberty deployment

Dependencies

  1. There are several feature blueprints which are expected to merge into the master branch alongside these changes. These features are to facilitate future improvements in the Mitaka development timeframe and may be backported to Liberty. The feature blueprints are marked as dependent in Launchpad.

  2. The final release of OpenStack-Ansible’s Liberty release is entirely dependent on OpenStack’s Liberty release.

Implementation

Assignee(s)

Work items

See Assignees.

Testing

No changes to the current testing and or gating framework will be made. Each change that is made to a service to bring forward new configs and settings will be required to pass the same gate tests as are required by our production systems.

Documentation impact

All changes made will require DocImpact tags in the commit messages in order to track the changes required for documentation.

References