stable/havana status WAS Re: Question
2014/1/22 Gary Kotton <gkotton@vmware.com>:
Hi, This morning I saw that the devstack patch was through and reran most of the checks. For some reason I am unable to approve. Any ideas?
Yes, +1 approve permission was removed to help solving gate resets since stable-maint team was not honoring Jan 17 post from Sean which still applies: [openstack-dev] [all] stable/havana currently blocked - do not approve or recheck stable/* patches Thierry also forwarded it to stable-maint list yesterday. While devstack grizzly should be fixed now, stable/havana has other issues still, so please wait until further notice on stable-maint and/or openstack-dev. Cheers, Alan
On 1/22/14 3:41 PM, "Alan Pevec" <apevec@gmail.com> wrote:
2014/1/22 Gary Kotton <gkotton@vmware.com>:
Hi, This morning I saw that the devstack patch was through and reran most of the checks. For some reason I am unable to approve. Any ideas?
Yes, +1 approve permission was removed to help solving gate resets since stable-maint team was not honoring Jan 17 post from Sean which still applies: [openstack-dev] [all] stable/havana currently blocked - do not approve or recheck stable/* patches
Thierry also forwarded it to stable-maint list yesterday. While devstack grizzly should be fixed now, stable/havana has other issues still, so please wait until further notice on stable-maint and/or openstack-dev.
Thanks for the update. The gating now passes. Will these delays affect the release date of the next stable version?
Cheers, Alan
On 01/22/2014 08:41 AM, Alan Pevec wrote:
2014/1/22 Gary Kotton <gkotton@vmware.com>:
Hi, This morning I saw that the devstack patch was through and reran most of the checks. For some reason I am unable to approve. Any ideas?
Yes, +1 approve permission was removed to help solving gate resets since stable-maint team was not honoring Jan 17 post from Sean which still applies: [openstack-dev] [all] stable/havana currently blocked - do not approve or recheck stable/* patches
Thierry also forwarded it to stable-maint list yesterday. While devstack grizzly should be fixed now, stable/havana has other issues still, so please wait until further notice on stable-maint and/or openstack-dev.
So with the grizzly patch in, do we have a stable/havana recheck that's currently passing? If we can convince ourselves that stable/havana patches can pass again, we can get the Approve bit turned back on. Sorry for the blunt hammer we used there. With the state of everything we couldn't afford people making mistakes because they weren't keeping up with the -dev list. I was hoping stable/havana in the subject thread would actually make it so people would read it. -Sean -- Sean Dague http://dague.net
On 1/22/14 4:00 PM, "Sean Dague" <sean@dague.net> wrote:
On 01/22/2014 08:41 AM, Alan Pevec wrote:
2014/1/22 Gary Kotton <gkotton@vmware.com>:
Hi, This morning I saw that the devstack patch was through and reran most of the checks. For some reason I am unable to approve. Any ideas?
Yes, +1 approve permission was removed to help solving gate resets since stable-maint team was not honoring Jan 17 post from Sean which still applies: [openstack-dev] [all] stable/havana currently blocked - do not approve or recheck stable/* patches
Thierry also forwarded it to stable-maint list yesterday. While devstack grizzly should be fixed now, stable/havana has other issues still, so please wait until further notice on stable-maint and/or openstack-dev.
So with the grizzly patch in, do we have a stable/havana recheck that's currently passing? If we can convince ourselves that stable/havana patches can pass again, we can get the Approve bit turned back on.
Out of 11 rechecks done this morning 8 have passed successfully. This seems to be in line with the master jenkins behavior. I am not sure if it is possible, but would it be possible to have a stable queue jenkins?
Sorry for the blunt hammer we used there. With the state of everything we couldn't afford people making mistakes because they weren't keeping up with the -dev list. I was hoping stable/havana in the subject thread would actually make it so people would read it.
-Sean
-- Sean Dague https://urldefense.proofpoint.com/v1/url?u=http://dague.net/&k=oIvRg1%2BdG AgOoM1BIlLLqw%3D%3D%0A&r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D% 0A&m=IwIrXus%2FlNUapfq2rjI%2FVbvQOy2INJUgV7wbFET3Teg%3D%0A&s=ba6f61cdea97a 93fa5805d67e94959b89815bb98d4a139fd3643d32d8bf13307
Gary Kotton wrote:
I am not sure if it is possible, but would it be possible to have a stable queue jenkins?
I asked that question before, and at this point it's not possible, as stable branch commits may affect master tests. That said, it's something we should explore. Same for milestone-proposed branch. If there is a way to isolate it from the master gate queue, that would solve a lot of release-related time-sensitive issues. -- Thierry Carrez (ttx)
On 01/22/2014 12:47 PM, Thierry Carrez wrote:
Gary Kotton wrote:
I am not sure if it is possible, but would it be possible to have a stable queue jenkins?
I asked that question before, and at this point it's not possible, as stable branch commits may affect master tests.
That said, it's something we should explore. Same for milestone-proposed branch. If there is a way to isolate it from the master gate queue, that would solve a lot of release-related time-sensitive issues.
This would need some really clever logic to ensure that we weren't breaking upgrades. I think it's something that someone could investigate for zuul additions. In the general case it would mean zuul would need to support dynamic queue merge, when we realize we have a set of branches in flight that actually need upgrade path tested across them. -Sean -- Sean Dague Samsung Research America sean@dague.net / sean.dague@samsung.com http://dague.net
On 1/22/14 8:29 PM, "Sean Dague" <sean@dague.net> wrote:
On 01/22/2014 12:47 PM, Thierry Carrez wrote:
Gary Kotton wrote:
I am not sure if it is possible, but would it be possible to have a stable queue jenkins?
I asked that question before, and at this point it's not possible, as stable branch commits may affect master tests.
That said, it's something we should explore. Same for milestone-proposed branch. If there is a way to isolate it from the master gate queue, that would solve a lot of release-related time-sensitive issues.
This would need some really clever logic to ensure that we weren't breaking upgrades. I think it's something that someone could investigate for zuul additions. In the general case it would mean zuul would need to support dynamic queue merge, when we realize we have a set of branches in flight that actually need upgrade path tested across them.
Not sure I really underhand that. The stable got branches we have are not included in the main branches. Are you referring to the infra?
-Sean
-- Sean Dague Samsung Research America sean@dague.net / sean.dague@samsung.com https://urldefense.proofpoint.com/v1/url?u=http://dague.net/&k=oIvRg1%2BdG AgOoM1BIlLLqw%3D%3D%0A&r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D% 0A&m=YVWRwhS3AZdl1Ua0u444oDB7bqA2%2FPZL1eddiQYWJVA%3D%0A&s=ada6fd2bc3fcdbb 4d559bf34e8468b0dbc2a61b6e5e32d1bc263c7c16d5448a6
On 01/22/2014 01:42 PM, Gary Kotton wrote:
On 1/22/14 8:29 PM, "Sean Dague" <sean@dague.net> wrote:
On 01/22/2014 12:47 PM, Thierry Carrez wrote:
Gary Kotton wrote:
I am not sure if it is possible, but would it be possible to have a stable queue jenkins?
I asked that question before, and at this point it's not possible, as stable branch commits may affect master tests.
That said, it's something we should explore. Same for milestone-proposed branch. If there is a way to isolate it from the master gate queue, that would solve a lot of release-related time-sensitive issues.
This would need some really clever logic to ensure that we weren't breaking upgrades. I think it's something that someone could investigate for zuul additions. In the general case it would mean zuul would need to support dynamic queue merge, when we realize we have a set of branches in flight that actually need upgrade path tested across them.
Not sure I really underhand that. The stable got branches we have are not included in the main branches. Are you referring to the infra?
Right now, branch isn't a construct that zuul knows about in scheduling. If it was, they way the interdependent queue gets built would need to change. For instance, landing grizzly changes, and master changes could happen in separate pipes, because there is no upgrade path between them (there is an upgrade path through havana, but we're not changing havana in either case). However if someone enqueues a havana change, we'd need to join those queues. Because now we have something that can be impacted in it's testing by in flight grizzly changes, and can impact in flight master changes. So it would introduce the idea of multiple parent changes in zuul. Which is all probably doable, but it's logic that doesn't exist. Unless you don't care about upgrades (which is basically currently the #1 most important thing to our users, so I'm going to say we do care about upgrades), you can't run the queues separately. Honestly we should be doing more upgrade testing with the proposed branches, which we don't. We still have a few exposed surfaces here where you can thread the needle and get an upgrade breaking change into a stable branch for forward upgrading. -Sean -- Sean Dague Samsung Research America sean@dague.net / sean.dague@samsung.com http://dague.net
participants (4)
-
Alan Pevec
-
Gary Kotton
-
Sean Dague
-
Thierry Carrez