Open Stack

On 09/27/2017 11:39 AM, Alex Schultz wrote:
> On Tue, Sep 26, 2017 at 11:57 PM, Tony Breeds <tony at 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 <tony at 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 :-)