On Mon, Oct 16, 2017 at 2:33 PM, Steven Dake (stdake) <std...@cisco.com> wrote: > Emilien, > > 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? Steve __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
