Open Stack

On Wed, Sep 27, 2017 at 5:37 PM, Tony Breeds <tony at bakeyournoodle.com> wrote:
> On Wed, Sep 27, 2017 at 10:39:13AM -0600, Alex Schultz wrote:
>
>> 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.
>
> There are 2 separate aspects here:
> 1) What changes are appropriate on stable/* branches ; and
> 2) How long to stable/* stay around for.
>
> Looking at 1.  I totally get that deployment projects have a different
> threshold on the bugfix/feature line.  That's actually the easy part to
> fix.  The point of the stable policy is to give users some assurance
> that moving from version x.y.z -> x.Y.Z will be a smooth process.  We
> just need to capture that intent in a policy that works in the context
> of a deployment project.

It makes total sense to me. BTW we have CI coverage for upgrades from
Newton to Ocata (and Ocata to Pike is ongoing but super close; also
Pike to Queens is targeted to Queens-1 milestone) so you can see our
efforts on that front are pretty heavy.

> Looking at 2.  The stable policy doesn't say you *need* to EOL on
> Oct-11th  by default any project that asserts that tag is included but
> you're also free to opt out as long as there is a good story around CI
> and impact on human and machine resources.  We re-evaluate that from
> time to time.  As an example, group-based-policy otpted out of the
> kilo?, liberty and mitaka EOLs, recently dropped everything before
> mitaka.  I get that GBP has a different footprint in CI than tripleo
> does but it illustrates that there is scope to support your users within
> the current policy.

Again, it makes a lot of sense here. We don't want to burn too much CI
resources and keep strict minimum - also make sure we don't burn any
external team (e.g. stable-maint).

> I'm still advocating for crafting a more appropriate policy for
> deployment projects.

Cool, it's aligned with what Ben and Alex are proposing, iiuc.

>> >> 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.
>
> Right, I don't pretend to understand the ins-and-outs of tripleo but yes
> I think we're mostly agreeing on that point.
>
> https://review.openstack.org/#/c/507924/ buys everyone the space to make
> that evaluation.
>
> Yours Tony.

Thanks Tony for being open on the ideas; I find our discussion very
productive despite the fact we want to give up the tag for now.

So as a summary:

1) We discuss on 507924 to figure out yes/no we give up the tag and
which repos we do it.
2) Someone to propose an amendment to the existing stable policy or
propose a new policy.
3) Figure out if we can postpone TripleO Newton EOL and make sure
we're doing it right (e.g. having CI jobs working, not burning
anything etc).
4) On the long term, figure out how to break down THT (we'll probably
want a blueprint for that and some folks working on it).

Thanks,
-- 
Emilien Macchi