Re: [openstack-dev] [tripleo] Newton End-Of-Life (EOL) next month (reminder #1)

[Tony Breeds]

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

Re: [openstack-dev] [tripleo] Newton End-Of-Life (EOL) next month (reminder #1)

[Jeremy Stanley]

On 2017-09-28 11:13:56 +1000 (+1000), Tony Breeds wrote:
[...]
> I can see a policy looked more like:
> 
> Phase  Time frameSummary Changes Supported
> I  0-12 months   Maintained release  All bugfixes (that meet the
>   after release  criteria described below) are
>  appropriate
> IImore than 12   Legacy release  Only security patches are acceptable
>   months after
>   release
> 
> The 12 month mark is really only there to line up with our current EOL
> plans, if they changed then we'd need to match them.
[...]

And to be clear, the main reason to only allow very minimal changes
in the last phase is because at that point you no longer have
working CI for the previous release and so cannot test that your
patches don't break the upgrade path from that previous release.
-- 
Jeremy Stanley


signature.asc
Description: Digital signature
__
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

Re: [openstack-dev] [tripleo] Newton End-Of-Life (EOL) next month (reminder #1)

[Tony Breeds]

On Wed, Sep 27, 2017 at 10:17:16PM -0500, Ben Nemec wrote:
> 
> 
> On 09/27/2017 08:13 PM, Tony Breeds wrote:
> > On Wed, Sep 27, 2017 at 03:35:43PM -0500, Ben Nemec wrote:
> > > 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's mostly accurate but the policy also is an indication that
> > consumers should be moving along to newer releases.  For a whole host of
> > reasons that isn't working and it's a thing that we need to address as a
> > community.
> 
> Ah, I wasn't familiar with that aspect of it.  I guess that's a valid reason
> not to continue full support of stable branches even if you theoretically
> could.
> 
> > 
> > The current policy broadly defines 3 phases[1]:
> > 
> > Phase   Time frameSummaryChanges Supported
> > I   First 6 monthsLatest release All bugfixes (that meet the
> >   criteria described below) 
> > are
> >   appropriate
> > II  6-12 months   Maintained release Only critical bugfixes and
> >  after releasesecurity patches are 
> > acceptable
> > III more than 12  Legacy release Only security patches are 
> > acceptable
> >  months after
> >  release
> > 
> > I can see a policy looked more like:
> > 
> > PhaseTime frameSummary Changes Supported
> > I0-12 months   Maintained release  All bugfixes (that meet the
> >  after release  criteria described below) 
> > are
> > appropriate
> > II  more than 12 Legacy releaseOnly security patches are 
> > acceptable
> >  months after
> >  release
> > 
> > The 12 month mark is really only there to line up with our current EOL
> > plans, if they changed then we'd need to match them.
> 
> Wouldn't that still exclude the Ceph patch we're using as an example? Newton
> is over 12 months old at this point.

Re: [openstack-dev] [tripleo] Newton End-Of-Life (EOL) next month (reminder #1)

[Ben Nemec]

On 09/27/2017 08:13 PM, Tony Breeds wrote:

On Wed, Sep 27, 2017 at 03:35:43PM -0500, Ben Nemec wrote:
  

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's mostly accurate but the policy also is an indication that
consumers should be moving along to newer releases.  For a whole host of
reasons that isn't working and it's a thing that we need to address as a
community.


Ah, I wasn't familiar with that aspect of it.  I guess that's a valid 
reason not to continue full support of stable branches even if you 
theoretically could.




The current policy broadly defines 3 phases[1]:

Phase   Time frameSummaryChanges Supported
I   First 6 monthsLatest release All bugfixes (that meet the
  criteria described below) are
  appropriate
II  6-12 months   Maintained release Only critical bugfixes and
 after releasesecurity patches are 
acceptable
III more than 12  Legacy release Only security patches are 
acceptable
 months after
 release

I can see a policy looked more like:

PhaseTime frameSummary Changes Supported
I0-12 months   Maintained release  All bugfixes (that meet the
 after release  criteria described below) are
appropriate
II  more than 12 Legacy releaseOnly security patches are 
acceptable
 months after
 release

The 12 month mark is really only there to line up with our current EOL
plans, if they changed then we'd need to match them.


Wouldn't that still exclude the Ceph patch we're using as an example? 
Newton is over 12 months old at this point.





That said, I'm staunchly opposed to feature backports.  While I think it
makes perfect sense to allow backports like Giulio's,


Yup with my limited knowledge I think that review makes perfect sense to
backport.  It just doesn't match the *current* stable policy.


  

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.


If splitting the repos has good technical benefits then cool, if it's
mostly about matching policy then I think altering the policy (or
defining a new one is a better solution)
  

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.


I'm not sure I follow but sure altering the timeline within reason is a
simple thing to do.


Yeah, that was not a fully formed thought in my head when I wrote it. 
:-)  I guess I was thinking of somehow allowing more time for features 
to be done after the rest of OpenStack cuts its release, but I don't 
actually know if that would help.


One (maybe crazy) thought I had after writing all this was the 
possibility of allowing feature backports for a limited time after 
release in the deployment projects.  Say feature backports are only 
allowed up to M-1 of the next release.  I'm not at all sure I like the 
idea but it has some interesting implications, both good and bad.  Like 
no more FFE's - if you miss release you just have to do the extra work 
of backporting if you still want it in.  So there's motivation to get 
stuff done on time, but less panic around release time.  Of course, 
somebody's got to review all those backports so like I said I'm not 
convinced it's a good idea, but it's an idea. :-)


__
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

Re: [openstack-dev] [tripleo] Newton End-Of-Life (EOL) next month (reminder #1)

[Emilien Macchi]

On Wed, Sep 27, 2017 at 5:37 PM, Tony Breeds  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

__
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

Re: [openstack-dev] [tripleo] Newton End-Of-Life (EOL) next month (reminder #1)

[Tony Breeds]

On Wed, Sep 27, 2017 at 03:35:43PM -0500, Ben Nemec wrote:
 
> 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's mostly accurate but the policy also is an indication that
consumers should be moving along to newer releases.  For a whole host of
reasons that isn't working and it's a thing that we need to address as a
community.

The current policy broadly defines 3 phases[1]:

Phase   Time frameSummaryChanges Supported
I   First 6 monthsLatest release All bugfixes (that meet the
 criteria described below) are
 appropriate
II  6-12 months   Maintained release Only critical bugfixes and
after releasesecurity patches are acceptable
III more than 12  Legacy release Only security patches are 
acceptable
months after
release

I can see a policy looked more like:

PhaseTime frameSummary Changes Supported
I0-12 months   Maintained release  All bugfixes (that meet the
after release  criteria described below) are
   appropriate
II  more than 12 Legacy releaseOnly security patches are 
acceptable
months after
release

The 12 month mark is really only there to line up with our current EOL
plans, if they changed then we'd need to match them.

> That said, I'm staunchly opposed to feature backports.  While I think it
> makes perfect sense to allow backports like Giulio's,

Yup with my limited knowledge I think that review makes perfect sense to
backport.  It just doesn't match the *current* stable policy.


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

If splitting the repos has good technical benefits then cool, if it's
mostly about matching policy then I think altering the policy (or
defining a new one is a better solution)
 
> 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.

I'm not sure I follow but sure altering the timeline within reason is a
simple thing to do.

Yours Tony.

[1] https://docs.openstack.org/project-team-guide/stable-branches.html


signature.asc
Description: PGP signature
__
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

Re: [openstack-dev] [tripleo] Newton End-Of-Life (EOL) next month (reminder #1)

[Tony Breeds]

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.

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.

I'm still advocating for crafting a more appropriate policy for
deployment projects.
 
> >> 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.


signature.asc
Description: PGP signature
__
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

Re: [openstack-dev] [tripleo] Newton End-Of-Life (EOL) next month (reminder #1)

[Ben Nemec]

On 09/27/2017 11:39 AM, Alex Schultz wrote:

On Tue, Sep 26, 2017 at 11:57 PM, Tony Breeds  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  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 

Re: [openstack-dev] [tripleo] Newton End-Of-Life (EOL) next month (reminder #1)

[Emilien Macchi]

On Wed, Sep 27, 2017 at 9:39 AM, Alex Schultz  wrote:
[...]
> 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.

Thanks Alex for the notes, while I agree with you, I proposed:
https://review.openstack.org/507924 in the meantime.

I'm not entirely sure about the THT-extras and the fact it would add
another layer of complexity, but I'm happy to discuss about it.

Tony, Alex, Steve, (others of course) - if you can look at the
governance change and give feedback on it, that would help.

Thanks,
-- 
Emilien Macchi

__
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

Re: [openstack-dev] [tripleo] Newton End-Of-Life (EOL) next month (reminder #1)

[Alex Schultz]

On Tue, Sep 26, 2017 at 11:57 PM, Tony Breeds  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  
>> 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.

Thanks,
-Alex

> Yours Tony.
>
> __
> 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
>

__
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

Re: [openstack-dev] [tripleo] Newton End-Of-Life (EOL) next month (reminder #1)

[Tony Breeds]

On Tue, Sep 26, 2017 at 10:31:59PM -0700, Emilien Macchi wrote:
> On Tue, Sep 26, 2017 at 10:17 PM, Tony Breeds  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 :)
 
> 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.

Yours Tony.


signature.asc
Description: PGP signature
__
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

Re: [openstack-dev] [tripleo] Newton End-Of-Life (EOL) next month (reminder #1)

[Emilien Macchi]

On Tue, Sep 26, 2017 at 10:17 PM, Tony Breeds  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.

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.
-- 
Emilien Macchi

__
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

Re: [openstack-dev] [tripleo] Newton End-Of-Life (EOL) next month (reminder #1)

[Tony Breeds]

On Wed, Sep 27, 2017 at 06:55:13AM +0200, Giulio Fidente wrote:
> On 09/26/2017 06:58 PM, Emilien Macchi wrote:
> > Newton is officially EOL next month:
> > https://releases.openstack.org/index.html#release-series
> > 
> > As an action from our weekly meeting, we decided to accelerate the
> > reviews for stable/newton before it's too late.
> > This email is a reminder and a last reminder will be sent out before
> > we EOL for real.
> > 
> > If you need any help to get backport merged, please raise it here or
> > ask on IRC as usual.
> 
> I was thinking to backport this [1] into both ocata and newton.
> 
> It should be relatively safe as it is basically only a change for a
> default value which we'd like to make more production-friendly

According to https://releases.openstack.org/ both Ocata and Newton are
in Phase II which means "Only critical bugfixes and security patches are
acceptable"
(https://docs.openstack.org/project-team-guide/stable-branches.html#support-phases).
The bug associated with that review indicates it's a medium priority.

With that in mind I'd suggest that your review isn't appropriate for
backport.

Yours Tony.


signature.asc
Description: PGP signature
__
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

Re: [openstack-dev] [tripleo] Newton End-Of-Life (EOL) next month (reminder #1)

[Giulio Fidente]

On 09/26/2017 06:58 PM, Emilien Macchi wrote:
> Newton is officially EOL next month:
> https://releases.openstack.org/index.html#release-series
> 
> As an action from our weekly meeting, we decided to accelerate the
> reviews for stable/newton before it's too late.
> This email is a reminder and a last reminder will be sent out before
> we EOL for real.
> 
> If you need any help to get backport merged, please raise it here or
> ask on IRC as usual.

I was thinking to backport this [1] into both ocata and newton.

It should be relatively safe as it is basically only a change for a
default value which we'd like to make more production-friendly

1. https://review.openstack.org/#/c/506330/
-- 
Giulio Fidente
GPG KEY: 08D733BA

__
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

Re: [openstack-dev] [tripleo] Newton End-Of-Life (EOL) next month (reminder #1)

[Tony Breeds]

On Tue, Sep 26, 2017 at 10:58:46AM -0600, Emilien Macchi wrote:
> Newton is officially EOL next month:
> https://releases.openstack.org/index.html#release-series
> 
> As an action from our weekly meeting, we decided to accelerate the
> reviews for stable/newton before it's too late.
> This email is a reminder and a last reminder will be sent out before
> we EOL for real.
> 
> If you need any help to get backport merged, please raise it here or
> ask on IRC as usual.

For projects that need to be integreated with upper-constraints
the deadline is this week though given I tend to do my stable/* release
reviews on Mondays I'd accepet anything that's ready for review then.

For projects that don't need to be integrated with upper-constratints
the deadline is Oct 11th.  I'll be generating my list of repos this
week for review by the community.

Yours Tony.


signature.asc
Description: PGP signature
__
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