Define our master policy
The blueprint has been created for puppet-nova, but affects all modules:
Here are the problems that lead us to write this blueprint:
- OpenStack projects use to update their configuration files and API every
release, with all the time backward compatibility support. When using
deprecated configuration parameters, OpenStack projects uses WARNING level
in logging files (visible when the program starts), that warn operators to
update configuration files so they have the latest options.
- Since the beginning of the Puppet modules project, master branch has always been
the development branch and be used to integrate features from OpenStack master
or very recent release. Until now, master branch always meant to be used to test
the last stable OpenStack release.
- Over the time, our community grew and we’ve got contributions and
more feedback from operators world that complained master branch was broken
for a recent stable release.
- When fixing a bug in master, we often miss to backport it to stable branches
because it requires manual work (cherry-pick). This is problem #4: what can
we backport to stable branches?
- Accept that master branch is not supposed to work on stable releases of OpenStack.
- Functional testing CI jobs should pass using the latest testing package repositories
from the Ubuntu and RHEL distributions.
- Submit a feature in master only if it can be tested by functional testing CI jobs.
We make an announcement on the mailing-list each time we update the repositories for
the functional tests.
- Help developers to easily backport patches to stable branches when needed.
- Creating a branch called ‘future/<release>’ for those changes that would get merged
back into master and then into ‘stable/<release>’ when that branch is created.
Data model impact
Data model needs to be backward compatible at least 2 releases.
Module API impact
Module API needs to be backward compatible at least 2 releases.
Deployers will need to be more careful if they used to run master branches.
- use master if they target a deployment with the current development version.
- use stable branches if they plan to deploy a stable version of OpenStack.
Developers will need to figure if their patch can be tested by the current state of master.
Also, they will need to be more engaged in backport policy and make sure to cherry-pick interesting
bugfixes and features to the right stable branches.
- Primary assignee:
Beaker jobs are in place and working on master (which is running Kilo at this time).
We need to update the Wiki to explain this policy to our contributors.