Open Stack

On Wed, Sep 27, 2017 at 08:14:19PM -0700, Emilien Macchi wrote:
> 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.

Yup I hope nothing I said implied a lack of comittment from the tripleo
team.  If I understand the context of the 'minor update' work once it's
done you'll be ahead of the curve ;P
 
> > 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).

Cool.
 
> > 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.

Yup.
 
> >> >> 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.

You're all welcome.  This community is good at trying to see problems
from all sides and acting with maturity :)

\o/
 
> 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.

Yup, as I said on the review I think removing the tag is the right thing
to do right now.

> 2) Someone to propose an amendment to the existing stable policy or
> propose a new policy.

Yup, though to level set this wont be an immediate action.  I'd like to
have a draft available before the Sydney summit

> 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).

+1, as always let me know what I can do to help with this.

Yours Tony.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170929/9b5e387a/attachment-0001.sig>