settingsLogin | Registersettings

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

0 votes

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


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked Sep 28, 2017 in openstack-dev by emilien_at_redhat.co (36,940 points)   2 6 9

15 Responses

0 votes

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.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

responded Sep 26, 2017 by Tony_Breeds (19,660 points)   3 6 11
0 votes

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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Sep 27, 2017 by Giulio_Fidente (3,980 points)   4 4
0 votes

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.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

responded Sep 27, 2017 by Tony_Breeds (19,660 points)   3 6 11
0 votes

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

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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Sep 27, 2017 by emilien_at_redhat.co (36,940 points)   2 6 9
0 votes

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@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 :)

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.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

responded Sep 27, 2017 by Tony_Breeds (19,660 points)   3 6 11
0 votes

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

Thanks,
-Alex

Yours Tony.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Sep 27, 2017 by aschultz_at_redhat.c (5,800 points)   2 2 4
0 votes

On Wed, Sep 27, 2017 at 9:39 AM, Alex Schultz aschultz@redhat.com 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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Sep 27, 2017 by emilien_at_redhat.co (36,940 points)   2 6 9
0 votes

On 09/27/2017 11:39 AM, Alex Schultz wrote:
On Tue, Sep 26, 2017 at 11:57 PM, Tony Breeds tony@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@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Sep 27, 2017 by Ben_Nemec (19,660 points)   2 3 3
0 votes

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.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

responded Sep 28, 2017 by Tony_Breeds (19,660 points)   3 6 11
0 votes

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 frame Summary Changes Supported
I First 6 months Latest release All bugfixes (that meet the
criteria described below) are
appropriate
II 6-12 months Maintained release Only critical bugfixes and
after release security 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:

Phase Time frame Summary Changes Supported
I 0-12 months Maintained release All bugfixes (that meet the
after release criteria described below) are
appropriate
II more 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.

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


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

responded Sep 28, 2017 by Tony_Breeds (19,660 points)   3 6 11
...