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.
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.
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
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.
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.
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 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 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.
Impacts must be noted in the commit messages for each change.
This change is to allow development of a production grade Liberty deployment
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.
All changes made will require DocImpact tags in the commit messages in order to track the changes required for documentation.