Steve, 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. Regards -steve On 10/16/17, 8:57 AM, "Steven Hardy" <[email protected]> wrote: On Mon, Oct 16, 2017 at 2:33 PM, Steven Dake (stdake) <[email protected]> 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: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
