Open Stack

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" <shardy at redhat.com> wrote:

    On Mon, Oct 16, 2017 at 2:33 PM, Steven Dake (stdake) <stdake at 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-request at lists.openstack.org?subject:unsubscribe
    http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev