On 09/27/2017 11:39 AM, Alex Schultz wrote:
On Tue, Sep 26, 2017 at 11:57 PM, Tony Breeds <t...@bakeyournoodle.com> wrote:
On Tue, Sep 26, 2017 at 10:31:59PM -0700, Emilien Macchi wrote:
On Tue, Sep 26, 2017 at 10:17 PM, Tony Breeds <t...@bakeyournoodle.com> wrote:
With that in mind I'd suggest that your review isn't appropriate for
If we have to give up backports that help customers to get
production-ready environments, I would consider giving up stable
policy tag which probably doesn't fit for projects like installers. In
a real world, users don't deploy master or Pike (even not Ocata) but
are still on Liberty, and most of the time Newton.
I agree the stable policy doesn't map very well to deployment projects
and that's something I'd like to address. I admit I'm not certain *how*
to address it but it almost certainly starts with a discussion like this
;P
I've proposed a forum session to further this discussion, even if that
doesn't happen there's always the hall-way track :)
One idea would be to allow trailing projects additional trailing on
the phases as well. Honestly 2 weeks for trailing for just GA is hard
enough. Let alone the fact that the actual end-users are 18+ months
behind. For some deployment project like tripleo, there are sections
that should probably follow stable-policy as it exists today but
elements where there's 3rd party integration or upgrade implications
(in the case of tripleo, THT/puppet-tripleo) and they need to be more
flexible to modify things as necessary. The word 'feature' isn't
necessarily the same for these projects than something like
nova/neutron/etc.
What proposing Giulio probably comes from the real world, the field,
who actually manage OpenStack at scale and on real environments (not
in devstack from master). If we can't have this code in-tree, we'll
probably carry this patch downstream (which is IMHO bad because of
maintenance and lack of CI). In that case, I'll vote to give up
stable:follows-policy so we can do what we need.
Rather than give up on the stable:follows policy tag it is possibly
worth looking at which portions of tripleo make that assertion.
In this specific case, there isn't anything in the bug that indicates
it comes from a user report which is all the stable team has to go on
when making these types of decisions.
We'll need to re-evaulate what stable-policy means for tripleo. We
don't want to allow the world for backporting but we also want to
reduce the patches carried downstream for specific use cases. I think
in the case of 3rd party integrations we need a better definition of
what that means and perhaps creating a new repository like THT-extras
that doesn't follow stable-policy while the main one does.
It's a little weird because essentially we want to provide a higher
level of support for stable branches than most of OpenStack. My
understanding is that a lot of the current stable branch policy came out
of the fact that there was a great deal of apathy toward stable branches
in upstream OpenStack and it just wasn't possible to say we'd do more
than critical bug and security fixes for older releases. Maybe we need
a stable-policy-plus tag or something for projects that can and want to
do more. And feel free to correct me if I'm misinterpreted the
historical discussions on this. :-)
That said, I'm staunchly opposed to feature backports. While I think it
makes perfect sense to allow backports like Giulio's, I was here when we
wasted the entire Mitaka cycle backporting things to Liberty and Kilo.
Sure, you can say we'll just be disciplined and pick and choose what we
backport, but I'm pretty sure we said the same thing back then. It's a
lot harder to say no when a customer/partner/your manager starts pushing
for something and you have no policy to back you up.
If we need to allow feature-ish backports for third-party, then I think
the third-party bits need to be split out into their own repo (they
probably should have been anyway) that has a different support policy.
I suppose we could try to implement that by convention in current tht,
but that will likely get messy when someone wants to backport a feature
that touches both third-party and core tht bits.
I guess maybe this is all going back to what we discussed at the PTG
retrospective about needing better modularity in TripleO. Instead of
having this monolithic all-singing, all-dancing tht repo that includes
the world, we need a well-defined interface for vendors to plug their
bits into TripleO so they can live where they want and be managed how
they want.
It feels a little weird to me to be arguing this side of it because I'm
pretty sure I've argued against splitting repos in the past. But I
think I would not say we kick all the vendor-integration bits out if we
do this, just that we provide the option for vendors to have their own
repos with their own stable backport policies without having to change
the policy for all of TripleO at the same time.
And I'm also open to other approaches like tweaking the cycle-trailing
definition to allow more time for this sort of thing. Maybe we could
eliminate some of the need for feature backports if we did that.
/wall-of-text :-)
__________________________________________________________________________
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
