[openstack-dev] [tc] [stable] [tripleo] [kolla] [ansible] [puppet] Proposing changes in stable policy for installers
Steven Dake (stdake)
stdake at cisco.com
Mon Oct 16 20:50:22 UTC 2017
I can see how #1 might be a problem in general and should be addressed in reasonable ways.
For #2, I think your analysis of the tech in use is accurate and if a new policy is made it be general yet inclusive enough to permit lifecycle management tools to improve and grow.
On 10/16/17, 8:57 AM, "Steven Hardy" <shardy at redhat.com> wrote:
On Mon, Oct 16, 2017 at 2:33 PM, Steven Dake (stdake) <stdake at cisco.com> wrote:
> I generally thought the stable policy seemed reasonable enough for lifecycle management tools. I’m not sure what specific problems you had in TripleO although I did read your review. Kolla was just tagged with the stable policy, and TMK, we haven’t run into trouble yet, although the Kolla project is stable and has been following the stable policy for about 18 months. If the requirements are watered down, the tag could potentially be meaningless. We haven’t experienced this specific tag enough to know if it needs some refinement for the specific use case of lifecycle management tools. That said, the follows release policy was created to handle the special case of lifecycle management tool’s upstream sources not being ready for lifecycle management tools to release at one coordinated release time.
We initially felt the policy was reasonable too, but there are a
couple of specific recurring pain points:
1. Services land features which require installer/management tool
updates late in the cycle, or the work to update the configuration
tooling just doesn't happen fast enough during a given cycle.
2. Vendor integrations, similar to (1) but specific to enabling vendor
backends e.g for Neutron etc - the work to enable configuring specific
vendor plugins tends to lag the upstream releases (sometimes
significantly) because most vendors are focussed on consuming the
stable branch releases, not the development/master releases.
In an ideal world the answer would be for everyone working on these
integrations to land the installer (e.g puppet/TripleO/Kolla/...)
patches earlier, but even with the concessions around cycle-trailing
deadlines we're finding that there is ongoing pressure to backport
integrations which (according to stable-maint policy) are strictly
"features" but are actually more integration or enablement of features
which do exist in the version of OpenStack we're deploying.
Several releases ago (before we adopted stable: follows-policy) we
tried to solve this by allowing selected feature backports, but this
was insufficiently well defined (and thus abused) so we need some way
to enable vendor integrations and exposure of new features in the
underlying services, without allowing a backport-everything floodgate
to open ;)
I think one difference between TripleO/Puppet and Kolla here is AFAIK
Kolla has several ways to customize the configuration of deployed
services in a fairly unconstrained way, whereas the openstack puppet
modules and TripleO publish interfaces via a somewhat more static
module and "service plugin" model, which improves discoverability of
features e.g for the TripleO UI but causes a headache when you
discover support for a new vendor Neutron plugin is required well
after the upstream release deadline has passed.
Hope that helps clarify somewhat?
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev