settingsLogin | Registersettings

Re: [openstack-dev] [Openstack-operators] LTS pragmatic example

0 votes

Excerpts from Davanum Srinivas (dims)'s message of 2017-11-15 03:04:38 +1100:

Flavio, Saverio,

Agree, that review may be a good example of what could be done. More info below.

Saverio said - "with the old Stable Release thinking this patch would
not be accepted on old stable branches."
My response - "Those branches are still under stable policy. That has
not changed just because of an email thread or a discussion in Forum"

Which stable policy does that patch violate? It's clearly a bug
because the wrong information is being logged. I suppose it goes
against the string freeze rule? Except that we've stopped translating
log messages so maybe we don't need to worry about that in this case,
since it isn't an exception.

Saverio said - "Let's see if this gets accepted back to stable/newton"
My response - "The branch the review is against is still under stable
policy. So things that will or will not be backported will not change"

Saverio said - "Please note that a developers/operators that make the
effort of fixing this in master, should do also all the cherry-pickes
back. We dont have any automatic procudure for this."
My response - "How the cherry-picks are done for stable branches will
not change. This is a stable branch, so there is no automatic
procedure for backporting"

Do we really not have any automation for proposing a cherry-pick
back through multiple branches? I know it can be done with a bunch
of clicks in gerrit, but it seems like it should be possible to
automate. Can someone write that script and put it into the
release-tools repo?

I really want folks to help with stable first, learn how things are
done and then propose changes to stable branch policies and help
execute them

If folks want to chase LTS, then we are outlining a procedure/process
that is a first step towards LTS eventually.

Thanks,
Dims

On Wed, Nov 15, 2017 at 2:46 AM, Flavio Percoco flavio@redhat.com wrote:

On 14/11/17 22:33 +1100, Davanum Srinivas wrote:

Saverio,

This is still under the stable team reviews... NOT LTS.

Your contacts for the Nova Stable team is ...
https://review.openstack.org/#/admin/groups/540,members

Let's please be clear, we need new people to help with LTS plans.
Current teams can't scale, they should not have to and it's totally
unfair to expect them to do so.

I think you may have misunderstood Saverio's email. IIUC, what he was trying
to
do was provide an example in favor of the LTS branches as discussed in
Sydney,
rather than requesting for reviews or suggesting the stable team should do
LTS.

Flavio

On Tue, Nov 14, 2017 at 8:02 PM, Saverio Proto zioproto@gmail.com wrote:

Hello,

here an example of a trivial patch that is important for people that
do operations, and they have to troubleshoot stuff.

with the old Stable Release thinking this patch would not be accepted
on old stable branches.

Let's see if this gets accepted back to stable/newton

https://review.openstack.org/#/q/If525313c63c4553abe8bea6f2bfaf75431ed18ea

Please note that a developers/operators that make the effort of fixing
this in master, should do also all the cherry-pickes back. We dont
have any automatic procudure for this.

thank you

Saverio

--
@flaper87
Flavio Percoco


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 Nov 14, 2017 in openstack-dev by Doug_Hellmann (87,520 points)   3 4 4

4 Responses

0 votes

Which stable policy does that patch violate? It's clearly a bug
because the wrong information is being logged. I suppose it goes
against the string freeze rule? Except that we've stopped translating
log messages so maybe we don't need to worry about that in this case,
since it isn't an exception.

Well, I also would like to understand more about stable policy violations.
When I proposed such patches in the past for the release N-2 I have
always got the answer: it is not a security issue so it will not be merged.

This is a good example of how things have been working so far:

https://review.openstack.org/#/q/677eb1c4160c08cfce2900495741f0ea15f566fa

This cinder patch was merged in master. It was then merged in Mitaka.
But it was not merged in Liberty just because "only security fixes" were
allowed at that point.

You can read that in the comments:
https://review.openstack.org/#/c/306610/

Is this kind of things going to change after the discussion in Sydney ?
The discussion is not enough ? what we need to get done then ?

thank you

Saverio


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 Nov 14, 2017 by saverio.proto_at_swi (860 points)   1 3
0 votes

Saverio,

Please see this :
https://docs.openstack.org/project-team-guide/stable-branches.html for
current policies.

On Wed, Nov 15, 2017 at 3:33 AM, Saverio Proto saverio.proto@switch.ch wrote:

Which stable policy does that patch violate? It's clearly a bug
because the wrong information is being logged. I suppose it goes
against the string freeze rule? Except that we've stopped translating
log messages so maybe we don't need to worry about that in this case,
since it isn't an exception.

Well, I also would like to understand more about stable policy violations.
When I proposed such patches in the past for the release N-2 I have
always got the answer: it is not a security issue so it will not be merged.

This is a good example of how things have been working so far:

https://review.openstack.org/#/q/677eb1c4160c08cfce2900495741f0ea15f566fa

This cinder patch was merged in master. It was then merged in Mitaka.
But it was not merged in Liberty just because "only security fixes" were
allowed at that point.

You can read that in the comments:
https://review.openstack.org/#/c/306610/

Is this kind of things going to change after the discussion in Sydney ?
The discussion is not enough ? what we need to get done then ?

thank you

Saverio


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

--
Davanum Srinivas :: https://twitter.com/dims


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 Nov 14, 2017 by Davanum_Srinivas (35,920 points)   2 4 6
0 votes

Let's focus our energy on the etherpad please

https://etherpad.openstack.org/p/LTS-proposal

On Wed, Nov 15, 2017 at 3:35 AM, Davanum Srinivas davanum@gmail.com wrote:
Saverio,

Please see this :
https://docs.openstack.org/project-team-guide/stable-branches.html for
current policies.

On Wed, Nov 15, 2017 at 3:33 AM, Saverio Proto saverio.proto@switch.ch wrote:

Which stable policy does that patch violate? It's clearly a bug
because the wrong information is being logged. I suppose it goes
against the string freeze rule? Except that we've stopped translating
log messages so maybe we don't need to worry about that in this case,
since it isn't an exception.

Well, I also would like to understand more about stable policy violations.
When I proposed such patches in the past for the release N-2 I have
always got the answer: it is not a security issue so it will not be merged.

This is a good example of how things have been working so far:

https://review.openstack.org/#/q/677eb1c4160c08cfce2900495741f0ea15f566fa

This cinder patch was merged in master. It was then merged in Mitaka.
But it was not merged in Liberty just because "only security fixes" were
allowed at that point.

You can read that in the comments:
https://review.openstack.org/#/c/306610/

Is this kind of things going to change after the discussion in Sydney ?
The discussion is not enough ? what we need to get done then ?

thank you

Saverio


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

--
Davanum Srinivas :: https://twitter.com/dims

--
Davanum Srinivas :: https://twitter.com/dims


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 Nov 14, 2017 by Davanum_Srinivas (35,920 points)   2 4 6
0 votes

On 11/14/2017 10:58 AM, Davanum Srinivas wrote:
Let's focus our energy on the etherpad please

https://etherpad.openstack.org/p/LTS-proposal

On Wed, Nov 15, 2017 at 3:35 AM, Davanum Srinivas davanum@gmail.com wrote:

Saverio,

Please see this :
https://docs.openstack.org/project-team-guide/stable-branches.html for
current policies.

On Wed, Nov 15, 2017 at 3:33 AM, Saverio Proto saverio.proto@switch.ch wrote:

Which stable policy does that patch violate? It's clearly a bug
because the wrong information is being logged. I suppose it goes
against the string freeze rule? Except that we've stopped translating
log messages so maybe we don't need to worry about that in this case,
since it isn't an exception.

Well, I also would like to understand more about stable policy violations.
When I proposed such patches in the past for the release N-2 I have
always got the answer: it is not a security issue so it will not be merged.

This is a good example of how things have been working so far:

https://review.openstack.org/#/q/677eb1c4160c08cfce2900495741f0ea15f566fa

This cinder patch was merged in master. It was then merged in Mitaka.
But it was not merged in Liberty just because "only security fixes" were
allowed at that point.

You can read that in the comments:
https://review.openstack.org/#/c/306610/

Is this kind of things going to change after the discussion in Sydney ?
The discussion is not enough ? what we need to get done then ?

thank you

Saverio


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

--
Davanum Srinivas :: https://twitter.com/dims

Heh, I'm reading this thread after approving all of those patches.

The answer as to whether it's appropriate or not, is "it depends".
Depends on the patch, depends on the age of the branch, etc.

In this case, newton is in phase 3 so normally it's only security or
critical fixes allowed, but in this case it's so trivial and so
obviously wrong that I was OK with approving it just to get it in before
we end of life the branch.

So, it depends. And because it depends, that's also why we don't
automate the backport of every fix made on master. Because guess what,
we also backport "fixes" that introduce regressions, and when you do
that to n-1 (Pike at this point) then you still have a lot of time to
detect that and fix it upstream, but regressing things on the oldest
branch leaves very little time to (1) have it detected and (2) get it
fixed before end of life.

--

Thanks,

Matt


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 Nov 15, 2017 by mriedemos_at_gmail.c (15,720 points)   2 3 4
...