Wednesday, 2015-04-15

*** dims_ has joined #openstack-relmgr-office00:35
*** dims has quit IRC00:36
*** dims_ has quit IRC02:21
*** eglynn has quit IRC07:33
*** eglynn has joined #openstack-relmgr-office07:33
*** eglynn has quit IRC07:47
Kiallttx: excellent :) I see you tagged+uploaded to LP.. Thanks :)07:52
* Kiall gets back to Kilo testing :)07:52
*** eglynn has joined #openstack-relmgr-office08:05
*** eglynn has quit IRC08:16
*** eglynn has joined #openstack-relmgr-office08:27
sdaguettx: so, are we at the point of branching GR?10:14
ttxsdague: yes10:15
ttxWill do with Doug's peer-review in a couple hours. You can play along if you are free10:16
ttxCurrenbtly brainstorming what we need to do at https://etherpad.openstack.org/p/the-big-thaw10:16
*** zz_johnthetubagu is now known as johnthetubaguy11:07
*** dims has joined #openstack-relmgr-office11:08
dhellmannttx: good morning/afternoon12:18
ttxdhellmann: o/12:18
ttxdhellmann: I dumped notes at https://etherpad.openstack.org/p/the-big-thaw12:19
dhellmannttx: give me a minute to read that and eat my toast?12:19
ttxyep12:19
dhellmannttx: do we have stable/kilo branches for projects yet, or are they still proposed/kilo?12:20
ttxthey are proposed/kilo until release day, so that I own the ACLs12:20
dhellmannk12:20
ttxs/I/Release Managers/12:20
ttx(of which you are a member)12:20
ttxbut we pushed a change so that stable/kilo reqs sync to proposed/kilo if stable/kilo doesn't exist12:21
dhellmannah! that was the missing piece12:21
ttxthx to fungi for that12:22
dhellmannok, so are we creating stable/kilo or proposed/kilo branches for the clients, too?12:23
dhellmannthat is, are you and I doing it this morning?12:23
ttxI think that's the simplest way to ensure they are done and properly done12:23
dhellmannok12:24
dhellmannand I see there's a list of the current release numbers that we can use for that12:24
ttxyes, and a few question marks12:24
dhellmannI think probably nothing uses the other clients listed there?12:26
ttxLooks like step 1 is safe, I can do that while you process and crosscheck the lib list12:26
dhellmannmarconiclient should be completely deprecated, right?12:26
ttxright, nothing in the integrated list (the things that actually use stable/kilo) uses the "other libs" afaict12:27
dhellmannk, I'm looking for the script I used to create the branches. I feel like it was rccut.sh but that seems to be creating proposed branches not stable12:27
ttxI may have missed libs between the oslo ones (already done) and the not-yet-done12:27
dhellmannok, I'll check the project list12:28
ttxosprofiler is used12:28
ttx(cinder glance heat trove)12:28
sdagueit would be good to push a fake change to the stable/kilo req once the branch is cut and make sure all the devstack-gate logic is still working for this12:28
ttxwe can push a .gitreview update12:29
dhellmannsdague: all of the branches will need to have their .gitreview files updated to add the defaultbranch -- right12:29
ttxadded to procedure12:29
sdaguettx: did you actually look at - https://review.openstack.org/#/c/172435/ - or script -2 it?12:30
ttxI fast-copypasted it. FWIW we usually don't get through the hassle of updating that for propsoed/* and pass the branch to the git-review command.12:31
ttxI don't mind it being there though12:31
ttxchnaged to 012:32
dhellmannttx: I'm not sure what to do with the heat-cfntools or heat-translator. Leave them for now?12:33
ttxthey are not consumed as libs afaict12:33
ttxI'd leave them out for now. Theyt are released without stable curently12:33
ttxarh, typing too fast12:34
dhellmannok -- we should no longer be releasing anything without a stable branch, but we can fix that when something breaks12:34
dhellmanndid you talk to annegentle about openstackdocstheme?12:35
ttxno12:35
dhellmannthat's probably safe to leave for now, I'll make a note of it12:36
dhellmannwhat about python-keystoneclient-federation and python-keystoneclient-kerberos12:38
ttxly understanding is that those don't really exist as far as kilo is concerned12:38
dhellmannk12:38
dhellmannyeah, let's do zaqarclient12:39
ttxand osprofiler, I'd say12:39
ttxdhellmann: I fear the only way we can get libs to prperly bump .Y on a new cycle is to remove tagging rights from PTLs.12:40
ttxand have more "release managers" to approve them round the clock12:40
dhellmannttx: we could also include a first liberty release in the work we do today12:41
dhellmannI agree on osprofiler, too12:41
ttxhmmm.12:41
dhellmannbecause we also have to update the minimums in master for liberty, right?12:43
ttxI guess we could (tag a first liberty thing). We just haven't asked the PTLs about it12:43
dhellmannI guess we don't *have* to12:43
ttxdhellmann: why ?12:43
ttxminimums are to signal broken versions12:43
dhellmannyeah, we can leave those until someone needs a feature in a newer version12:43
ttxosprofiler is stackforge, so I think we should lump it in "external libs"12:44
dhellmannah, that's why I couldn't find it12:44
dhellmannis that part of the rally project?12:44
ttxhmm12:44
ttxchecking12:45
ttxno12:45
dhellmannnot according to the governance repo12:45
ttxwe can always fix it later, but at this point I wouldn't reach out to stackforge stuff12:45
dhellmannagreed12:45
ttxsince in theory it's not our territory12:45
ttxalright, sounds like a plan12:46
dhellmannah, I updated my release-tools repo and found make_library_stable_branch.sh -- I knew I had a script for that :-)12:47
ttxAt which point in the process should we create the libraries stable branches ?12:47
* dhellmann thinks12:48
ttxnot sure that actually matters, so we could parallelize it12:48
ttxmaybe 2bis12:49
dhellmannprobably before we make changes to the caps, that way all of those go into the client libs as well as the projects12:49
ttxso between 2 and 3 in the proposed procedure ?12:49
ttxworks for me12:49
dhellmannhrm, although we won't actually want to release new versions with requirements changes12:49
dhellmannI guess capping is ok, we're not raising the minimum12:50
ttxack12:50
dhellmannyeah, between 2 and 312:50
ttxActually I think it's better to do it between 3 and 412:50
ttxso that capping is in place once we create the branch12:50
ttxprobably equivalent.12:51
dhellmann yeah, if we do it before 3 we get auto-updates of the caps in the client repos12:51
dhellmannif we wait until after, we have to trigger that some other way12:51
ttxadded between 2 and 312:52
ttxit's the new 312:52
ttxdhellmann, sdague: Do you know of any other library update coming from left field ? (see bottom of etherpad for known issues)12:53
ttxI'm also a bit uncertain with step 8 and could use jogo's experience before doing it12:54
ttxbut nothing that prevents us from doing the earlier steps12:54
dhellmannyeah, I'm not sure how that part works myself, jogo did that12:54
dhellmannI think gordc and I worked out the python-ceilometerclient issue yesterday12:55
ttxok, we'll sync with him before doing that part12:55
sdaguettx: let me look12:55
dhellmannthey're going to backport a couple of fixes once the branch is in place12:55
sdagueyeh, I guess the cross check is if it's in projects.txt it should have a stable branch12:56
dhellmannwow, pasting into an etherpad is borked for me12:56
sdaguettx: so keystonemiddleware is going to need 4 releases right?12:57
sdaguebecause it's got to have icehouse compat as well12:57
ttxsdague: didn't exist in icehouse time, so no, but otherwise yes12:57
sdaguewell, keystoneclient then12:57
ttxyes12:57
sdague3 releases for keystone middleware12:57
dhellmannthe middleware has a stable/juno branch already12:58
dhellmannsdague: do you mean "3 releases every time we fix something" or 3 releases today?12:58
ttxyes, security issues.12:58
sdaguedhellmann: today12:58
sdagueper comments at end12:58
ttxwell, not necessarily today, but certainly asap12:58
dhellmannk12:59
sdaguettx: honestly, for the amount of this I can keep in my head, that all seems fine12:59
ttxsdague: I'll take that12:59
ttxthx12:59
ttxOK, let me start by creating openstack/requirements stable/kilo branch from master HEAD12:59
dhellmannttx: do you want to double check that I didn't mess up my copy/paste in http://paste.openstack.org/show/203974/12:59
ttxchecking13:00
ttxdhellmann: sounds good. Any chance you could pastebin make_library_stable_branch.sh so that I check it ?13:01
ttxalso are you OK with me creating openstack/requirements stable/kilo branch from master HEAD now ?13:02
dhellmannttx: even better: http://git.openstack.org/cgit/openstack-infra/release-tools/tree/make_library_stable_branch.sh13:02
dhellmannttx: yep, we're ready for that13:02
ttxoh, that repo contains awesome stuff13:02
dhellmannI want to extend that script to create the .gitreview file change, too, but haven't done it yet13:02
ttxif that's the one you used for oslo it certainly was tested now13:02
ttxok, creating13:03
dhellmannI could add that to the script for today, or we could do these by hand13:03
ttxlet's do them by hand13:03
dhellmannk13:04
ttxok, we have a stable/kilo13:04
* ttx proposed .gitreview there13:04
ttxproposes*13:04
* dhellmann waits for it to appear13:06
ttxhttps://review.openstack.org/#/c/173815/13:07
dhellmannshall I fast-approve that?13:07
ttxI'd say yes13:07
dhellmann done13:07
ttxOK, should we hold until that merges before creating stable branches on libs ?13:08
* ttx prepares change to global-requirements to cap things13:08
dhellmannI think we can go ahead with those, but we'll want to wait for that to land before applying the caps13:08
dhellmannshall I run the script to create the lib branches?13:08
ttxdhellmann: yes. I prepare the caps while you run that13:09
dhellmannk, running now13:09
dhellmannhrm, this script checks that there is a launchpad milestone with the version requested13:10
dhellmannhow much do we actually care about that, since most are failing the check13:10
sdagueit's also important to make sure it's testing the right things, so once some test results get back we should look at which branches were put on disk13:11
ttxOh, what about python-openstacksdk13:11
ttxdhellmann: I think we can fast-create the missing milestones. Not sure it matters, but13:12
dhellmannI'll comment out that check for now13:12
dhellmannI'm not sure about the sdk13:12
*** dims has quit IRC13:13
ttxhmm stackforge too ?13:13
ttxlumping it with osprofiler13:14
*** dims has joined #openstack-relmgr-office13:15
dhellmannthat one is official now, but it hasn't been renamed13:15
dhellmannit's not used anywhere, though13:15
dhellmannwe can always come back and do it later13:15
ttxah. hm13:15
dhellmannok, my script finished and all of the branches in the libs are created13:18
dhellmannI'll start on .gitreview files now13:18
ttxshould we create the milestones in LP ?13:20
ttxProposed caps at: https://review.openstack.org/#/c/173842/13:21
dhellmannttx: it's up to you, we can make the milestones if it helps with tracking13:22
ttxdepends if those were actually created properly before...13:22
ttxGive me the list of missing ones and I'll check13:22
ttxif it's most, don't bother, I'll check them all13:22
dhellmannbarbicanclient, keystoneclient, neutronclient, novaclient, and keystonemiddleware *did* have them13:23
*** david-lyle has quit IRC13:24
ttxok, need to check that they are on the rigth series too13:24
ttxsince they weren't using them until now, but need them for proposing backports in LP13:24
ttxi'll just straighten them all13:24
* ttx just likes to play with LP13:25
ttxthat will take some time to straighten out13:27
dhellmannok, I'm submitting the .gitreview updates now13:29
dhellmannhmm, glancestore and django_openstack_auth had issues13:30
ttxwhat kind of issues13:32
dhellmannmy local repo wasn't updated so the commit went into the wrong branch13:33
dhellmanneasy to fix13:33
dhellmannhttps://review.openstack.org/#/q/owner:doug-hellmann+branch:stable/kilo+is:open,n,z13:33
dhellmannhrm, my script included an extra blank line. sorta ugly, but it shouldn't hurt anything13:34
ttxshould we approve those now ? Or wait until the main one is in ?13:37
ttxI guess now is as fine as ever13:37
dhellmannyeah, let's go ahead and approve them13:38
dhellmannand then we should wait for them to merge, probably, before approving the requirements caps13:38
dhellmannI'll double-check that change now13:38
ttxI'll approve the gitreview bumps13:38
dhellmannthe caps look good, and I gave it +2 for now so I remember that I've reviewed it :-)13:41
ttxarh, I don't have barbicanclient +2/aprv13:42
ttxdamn inclubated projects13:42
ttxerr... same for ceilometerclient13:42
ttxlooks like some ACLs need some love13:42
ttxwill approve what I can13:42
ttxLooks liek that is none of them13:43
ttxdhellmann: we need to add the stable-maint-core ACLto the libs13:44
ttxI can continue fixing LP if you work on that13:45
ttxOr I can switch context, just let me know13:45
dhellmannI can probably do the ceilometer client one, let me see13:46
dhellmannttx: is adding stable-maint-core acls something I can do through editing the acl files, or do I have to do that in gerrit directly?13:47
ttxyou have to propose a project-config change13:48
ttxideally we would do them all in one go13:48
dhellmannk13:48
ttxbasically copy the main project acl13:48
ttxas far as stable/* is concerned13:48
ttxso that the local $PROJECT-stable-maint gets rights13:48
dhellmannttx: sort of like what I was doing for oslo libs? https://review.openstack.org/#/c/173075/3/gerrit/acls/openstack/debtcollector.config,cm13:51
ttxsort of. see bottom of etherpad for example for nova13:53
ttxJust checking that stable-maint-core rights would be inherited13:53
ttxohn taht would because stable-maint-core is in every stable-maint group13:54
dhellmannyeah, the form I'm using is what we're doing with oslo now, where we add the global stable maint team and let the primary core team also have those rights (by not using exclusiveGroupPermissions)13:56
ttxdhellmann: so what I pasted at the bottom the etherpad, changing "nova" for $PROJECT13:56
dhellmannok13:56
dhellmannI'm not finding an acl file for glance_store13:56
ttxprobably uses glance.config13:56
ttxdirectly13:56
ttxI think acl files is mapped in the gerrit projects file13:57
dhellmannah13:57
dhellmannpython-glanceclient of all things13:57
dhellmannttx: https://review.openstack.org/17389214:05
ttxadjusting those milestones is full of unfun. Shouldn't have started14:06
dhellmann:-/14:06
ttxdhellmann: reviewed. There is one typo and an open question for projects that don't have stable teams yet14:11
ttxThose currently use their core teams to do stable IIRC14:11
ttxyeah, so zaqar-core instead of zaqar-stable-maint14:11
ttxbarbican doesn't even do stable branches :)14:12
ttxdesignate uses designate-milestone14:12
ttxbit of a mess14:13
ttxironic uses ironic-milestone14:13
ttxand openstackclient doesn't do stable yet, could reuse python-openstackclient-milestone for the time being14:14
dhellmannttx: fungi also suggested removing the "proposed" sections14:14
ttxthat can't hurt14:14
dhellmannok, I'll do that too14:14
dhellmannfor the teams that don't exist, do we want to create them or do we want to reuse an existing team?14:15
dhellmannfor example, barbican-stable-maint14:15
dhellmannwe don't want to add stable-maint-core to barbican-core14:15
dhellmannI could extend the rights to stable-maint-core like I did in oslo, though14:16
dhellmannor we could make a new team14:16
ttxI think we should reuse the existing ones for the moment14:20
dhellmannok14:20
ttxi.E. if they do stable with their -milestoen team, so be it14:20
ttxwe shoudl have that discussion of moving them to stable-maint system at some point, but not today14:20
dhellmannsome of these projects don't even have release teams14:20
dhellmannI can handle that the way we did in oslo, though, so no problem14:21
*** russellb has quit IRC14:38
*** russellb has joined #openstack-relmgr-office14:42
ttxalmost done with LP14:43
ttxdhellmann: ok, all set (phew). The benefit is that it points liberty to the X.Y+1.0 version14:49
ttxwill also simplify a lot the backporting targeting work14:50
ttxok, where are we standing now14:51
ttxdhellmann: stable/kilo req .gitreview bump still in gate14:53
ttxother gitreview bumps pending https://review.openstack.org/#/c/173892/14:53
dhellmannttx: https://review.openstack.org/173919 is a change to add those .gitreview changes as the branches are made, for next time14:53
ttxhttps://review.openstack.org/#/c/173842/ could use sdague eagle eyes as an additional +2 (do not approve just yet)14:54
ttxack14:54
dhellmannno rush on that script change, obviously14:54
dhellmannand if you have a less ugly way to do the newline handling, let me know14:54
ttxLooks like we are blocked at this point. We can propare the external lib caps, but let's wait for jogo to do that14:56
ttxI guess we could still encourage the backports to be proposed to the libs (step 5)14:57
ttxalthough ideally .gitreview bumps would merge first14:57
dhellmannyeah, they could submit patches on top of those .gitreview patches, but that's just going to use up more test nodes that could be running the jobs we're waiting for now14:57
dhellmannttx: we could remove the requirements caps in master, too, right?15:00
ttxdhellmann: you mean the Oslo ones ?15:01
dhellmannttx: all of it, but yeah15:01
ttxyes, we should propose that before we declare the freeze over and the gates open15:02
ttxAdding to procedure15:02
dhellmannI'll work on the patch15:02
ttxThis is longer and harder than expected, sorry to ruin your whole morning15:03
ttxbut I kinda expected that which is why I proactively seeked help :)15:03
dhellmannttx: I set today aside when you asked me to help. The only other thing I need to do today is call Delta to fix my flight to the summit (they rescheduled so I won't have time to make my connection)15:04
dhellmannttx: https://review.openstack.org/17392415:07
ttxdhellmann: lgtm15:11
ttxdhellmann: should we hold on that approval ? Or should we get that in and then remove the -2s from requirements master branch that we pushed during freeze ?15:12
*** david-lyle has joined #openstack-relmgr-office15:19
*** david-lyle_ has joined #openstack-relmgr-office15:19
dhellmannttx: it's probably safe to go ahead and approve it, since we do have the stable branches now15:20
ttxdhellmann: yeah. we should fine another +215:21
ttxfind*15:21
dhellmannttx: I pinged sdague in -infra15:25
*** russellb has quit IRC15:32
ttxLooks like some syncs got triggered already15:34
sdaguedhellmann: sorry, I'm in the middle of sorting out neutron for grenade15:35
sdaguewhat do you need me on15:35
ttxhttps://review.openstack.org/#/c/173827/115:35
ttxsdague: https://review.openstack.org/173924 +2/APRV15:35
*** russellb has joined #openstack-relmgr-office15:36
sdaguettx: yeh, so testing isn't working correctly - http://logs.openstack.org/15/173815/1/check/check-tempest-dsvm-full/0636154/logs/devstack-gate-setup-workspace-new.txt.gz15:43
ttxuh15:44
sdagueit's testing trove master15:45
sdaguethis was my concern around the proposed/* branches15:45
sdagueI think requirements also needs to be proposed/kilo15:45
ttxhm, that always fell back in previous releases though15:45
sdagueotherwise the test infrastructure doesn't work15:45
sdagueno, I don't think it did15:45
sdagueI think we just lucked out15:45
*** jogo has joined #openstack-relmgr-office15:45
ttxor did we use proposed/juno last cycle ?15:46
sdaguehonestly, I don't know15:46
sdaguethis is the reason I hound you about 'proposed' :)15:46
ttxhrm15:46
sdagueit's a piece of our infrastructure that's so infrequently used, no one knows if it's going to work15:46
sdagueanyway, we should probably take this to -infra and get opinions there15:47
ttxyeah, though that channel is already busy15:47
ttxjogo: thanks for joining. Looks like things just got on fire though15:50
ttxjogo: fyi we are following https://etherpad.openstack.org/p/the-big-thaw15:51
ttxFor step 8 we were planning to enlist your help to manipulate the cap script15:51
ttxBut then we should probably get the stable/kilo testing fixed first15:51
* jogo looks15:52
jogoso how did https://review.openstack.org/#/c/173834/1 happen15:54
jogottx: so want me to run cap.py on stable/kilo g-r?15:55
dhellmannjogo: yeah, none of us are sure how to do that15:55
ttxjogo: we have to do that at some point right ?15:56
ttxso better do it before we cut the RC2s so that we can sync the corresponding stuff in the release ?15:56
jogodhellmann: hopefully the help message is useful http://paste.openstack.org/show/20400515:56
jogottx: yes we have to do it at some point. Not sure if the point is before RC2s or after though15:57
dhellmannjogo: well, I meant, what else do I need on my system first, etc. -- can I just run it on any box with the code checked out?15:57
jogodhellmann: yes15:57
dhellmannk15:57
jogoyou just need a copy of a pip-freeze15:57
jogofrom a working gate run15:57
dhellmannah15:57
jogodhellmann: the script just pulls caps from pip-freeze output15:57
ttxjogo: I guess the question is... shoud we include that capped file in the release, or just have it in the stable branch post-release15:58
dhellmannoh, I thought it built a thing15:58
jogodhellmann: I would prefer you run the script this time instead of me, so more people know how to use it15:58
jogodhellmann: no, the next step is to push the patch up and see if it passes the tests. because it may not the first time15:58
dhellmannjogo: ok, where do I get the input you described? I guess we need a successful run first15:58
jogoin which case you may have to tweak the pins15:58
jogodhellmann: correct, I usually take the gate logs from a job15:59
jogottx: not sure which makes the most sense, doing it post release means we don't have to respin RC2s for everything15:59
dhellmannjogo: the whole log, or cutting out the freeze stuff at the end?16:00
* dhellmann should read cap.py16:00
jogodhellmann: see Iaf48bb069fdd7a19d614ce44b86abd9977c5f0c016:00
ttxjogo: we already pushed the caps for the openstack libs, so that will appear in rc2s16:00
jogohttps://review.openstack.org/#/c/147451/ in particular16:00
jogottx: I am less sure about the answer in light of the requirements.txt vs install_requires discussion16:01
jogobut either way works for me16:01
dhellmannjogo: ah, ok16:01
ttxmaybe we can defer the general lib capping to after release then. Less is more16:02
ttxno strong opinion on it16:02
jogodhellmann: I tried to make sure this was repeatable based on the commit message etc.16:02
dhellmannjogo: ok, I think I see what to do now, thanks for those pointers. I'll need to wait for some job running against stable/kilo to finish, and it sounds like sdague is saying at least some of those are looking at the wrong branches16:04
ttxyes, I propose we freeze the whole thing until we get that part fixed16:04
ttxdhellmann: still unsure when we want to do the external lib capping though16:05
dhellmannttx: yeah, let's wait on that16:05
ttxdhellmann: I take it you support the "cap all in RC2" idea ?16:05
dhellmannI would also be OK with capping now and adjusting if we need to for RC2. Is there a strong reason to wait?16:06
* dhellmann re-reads scrollback16:06
dhellmannttx: when you say "include that capped file in the release", do you mean the global-requirements.txt?16:07
dhellmannif we think we can get the caps in place before we cut rc2, that does seem ideal16:08
jogodhellmann: let me know if you have any further questions16:10
dhellmannjogo: ok, thanks. it looks like it'll be a while before we're ready to take that step16:11
ttxdhellmann: I mean include the external library capping in the requirements.txt files shipped in the reelase16:12
dhellmannttx: ok. I think that's a good goal.16:13
ttxok. That means we'll need them before we cut RC2s then, as described in the plan16:13
dhellmann++16:13
ttxbut let's solve that proposed/stable thing first16:13
*** david-lyle has quit IRC16:57
*** david-lyle has joined #openstack-relmgr-office17:09
*** david-lyle has quit IRC17:11
*** david-lyle has joined #openstack-relmgr-office17:11
*** eglynn has quit IRC17:13
Kiallttx: about? We found a few release critical issues in testing today :( Can we self-create a rc2 milestone or, so I leave that to you?17:36
ttxKiall: I can create it. Although it would probably be good to let the RC1 be tested a bit more, unless the issue prevents testing or eats data17:41
ttxIn the mean time add them to the kilo-rc-potential tag and get them fixed in master17:43
KiallSounds good17:44
ttxwe can open a RC2 tomoroow or Friday17:44
Kiallperfect17:45
*** johnthetubaguy is now known as zz_johnthetubagu17:48
ttxsdague: weird that that test run reports SUCCESS on https://review.openstack.org/#/c/173815/17:49
* ttx will be back in ~ one hour17:49
sdaguettx: it's not weird17:56
sdaguethere is no reason that test should fail, it was told to do a thing, and it could do it17:57
sdaguebut it doesn't mean it was the right test17:57
*** openstackstatus has quit IRC17:58
*** openstackstatus has joined #openstack-relmgr-office18:00
*** ChanServ sets mode: +v openstackstatus18:00
-openstackstatus- NOTICE: Gerrit has stopped emitting events so Zuul is not alerted to changes. We will restart Gerrit shortly to correct the problem.18:04
*** ChanServ changes topic to "Gerrit has stopped emitting events so Zuul is not alerted to changes. We will restart Gerrit shortly to correct the problem."18:04
*** david-lyle has quit IRC18:10
*** ChanServ changes topic to "OpenStack Release Managers office - Where weekly 1:1 sync points between release manager and PTLs happen - Logged at http://eavesdrop.openstack.org/irclogs/%23openstack-relmgr-office/"18:26
-openstackstatus- NOTICE: Gerrit has been restarted. New patches, approvals, and rechecks between 17:30 and 18:20 UTC may have been missed by Zuul and will need rechecks or new approvals added.18:26
ttxI'll lump the plan into https://etherpad.openstack.org/p/the-big-thaw19:15
dhellmannheat only has 2 patches, so we could start there and experiment to see how that goes before committing to do all of the projects19:15
*** fungi has joined #openstack-relmgr-office19:16
fungimy, what a lovely office you have19:16
ttxfungi: right? We follow https://etherpad.openstack.org/p/the-big-thaw19:16
dhellmannI've never seen leather upholstery in an irc channel before19:16
ttxit was here when I inherited it though19:17
*** AJaeger_ has joined #openstack-relmgr-office19:17
fungicorduroy upholstery? this must have been here since the 70s19:17
fungijust ftr, do we have a list of projects which will need a refs/heads/stable/kilo acl for milestone/rm folk?19:18
ttxDo we still need https://review.openstack.org/#/c/173892/19:18
* anteaya admires the lava lamp19:19
ttxyes we do19:19
fungittx: i believe so, yes19:19
fungithose people are just doing stable business as usual19:19
ttxI assigned people to steps 3-519:20
ttxI'll create the stable branches for all proposed/kilo19:20
sdagueso, sorry, was at a pediatric appoitment earlier and missed what the resolution is19:21
ttxall hail stable/kilo19:21
sdaguewe're doing stable branches early?19:21
fungisdague: proposed is dead, long live stable19:21
sdagueok, great19:21
sdaguethat simplifies a bunch of things19:21
ttxyes, it's more the future-proofind that convinced me19:21
ttxg19:21
fungirelease management/milestone peeps will have explicit acl-granted control over the stable/kilo branch until release day, then we can delete that section and the stable/* section will cover it for normal stable people19:22
ttxack, at least until we talk to see if we can skip that step19:22
fungirighty-o19:22
sdaguettx: so somewhere in here is also devstack-gate logic adds, grenade & devstack branching19:22
ttxok, creating branches, starting with heat19:22
sdaguewhich might be at the end of your current list19:22
ttxI thought you wanted to do it postrelease19:23
fungiworking on acls. where's the list of projects that need this, or should i just dig it out of the integrated release list on governance.o.o?19:23
ttxthis is more pre-RC2 and those will start appearing tomorrow19:23
sdagueso, if we have actual stable branches, we probably want to test upgrade to them19:23
ttxsdague: well, maybe yes, that would close the hole we have during proposed19:24
sdaguewe never did proposed/ on grenade or devstack before19:24
sdagueyeh19:24
ttxbut if we don't do that this time aroundno big deal19:24
fungiyep, i had started to look at what grenade logic additions would be needed to devstack-gate for kilo branches, but got sidetracked when it was pointed out that we had deeper problems19:24
sdagueit's probably a few days until we're ready for that anyway, I *definitely* want to get the rest of this grenade refactor done before the branch, which is why I've been kind of heads down on it19:24
ttxheat done : https://review.openstack.org/#/admin/projects/openstack/heat,branches19:25
ttxdhellmann: repropose at will19:25
* ttx does others19:25
ttxsdague: ++19:25
dhellmannttx: ok, I'm scripting it out19:25
sdaguettx: ok, are there any jobs you want me to inspect, or reviews you need out of me atm. Otherwise I'll walk away for a bit, and check back later for reviews you need me on.19:26
ttxthis day will forver be known as the Propogeddon19:26
fungithese are the ones which need the acl addition? http://governance.openstack.org/reference/tags/integrated-release.html#application-to-current-projects19:26
sdaguettx: will there be t-shirts?19:27
fungipropostable/kilo19:27
ttxfungi: + zaqar designate barbican manila19:27
fungittx: thanks!19:27
ttxoh I rememebr now19:29
ttxI also didn't want stable so that we wouldn't produce "stable.tar.gz"19:29
ttxanyway19:29
ttxignore me19:29
*** david-lyle has joined #openstack-relmgr-office19:30
fungiokay, so the only projects from that list which currently lack a refs/heads/proposed/* section are barbican and manila19:31
ttxI'll also already clean up propsoed branches that don't have any review posted yet19:32
dhellmannfungi: is there some way to tell git review that I want it to submit something to a branch other than what is in the .gitreview file? I'm not seeing the cli option19:32
ttxfungi: hmm manila should have it19:33
fungidhellmann: it's the first positional argument to the command line19:33
dhellmannah, I was looking for a flag19:33
fungittx: it's missing from the acl, doesn't mean there is no branch19:33
ttxoh ok19:33
dhellmannso here's 1 patch generated with my re-submit script: https://review.openstack.org/#/c/174042/19:34
dhellmannI would appreciate a quick review to make sure it looks ok before I call that one done and submit all of the others19:34
ttxfungi, dhellmann: OK for removing propsoed/kilo where there is no patch proposed yet ?19:34
ttxdhellmann: I'm on it19:34
fungiyep, sounds safe to me19:34
dhellmannttx: yeah, if we don't need the branch let's remove it19:35
ttxdhellmann: so.. you lose the changeID19:35
ttxis that on purpose ?19:35
ttxhttps://review.openstack.org/#/q/Ia563f4130c31baa4dcee3be3786ea3c49b6bad98,n,z shows master and porposed19:35
ttxwe usually keep the same for tracking19:35
fungiright, probably need to make sure you copy the change-id line from the commit message19:36
dhellmannttx: it wouldn't let me resubmit the patch with the same id, but maybe if I'm explicitly setting the branch it will?19:36
dhellmannlet me try again19:36
ttxit should yes19:36
fungiyeah, that would only object if proposing to the same branch it's already abandoned on19:36
dhellmannit's thinking hard...19:37
dhellmannfails because there are no new changes19:37
*** jeblair has joined #openstack-relmgr-office19:37
ttxweird19:37
fungidhellmann: in this case i think you can just abandon the incorrect one first. new change-id means new change anyway19:38
dhellmannfungi: I've abandoned the original one, but should submitting a new patch have un-abandoned it?19:38
dhellmann(with the same change-id)19:38
fungidhellmann: it'll be a different change-id than the one you originally proposed to that branch, yeah?19:39
fungisince this time you're copying the change-id from the one which was abandoned on the old branch19:39
dhellmannfungi: I re-ran the script and got a fresh copy of the original commit and tried to resubmit it19:39
dhellmannI should show you my script...19:39
fungithat might help19:39
dhellmannhttp://paste.openstack.org/show/204031/19:40
dhellmannthat function is called: rebase_one heat https://review.openstack.org/17370619:40
dhellmannwhere that url is the original changeset19:40
fungiideally you want Change-Id: Ia563f4130c31baa4dcee3be3786ea3c49b6bad98 in the commit message and the change to be proposed to stable/kilo19:40
ttxok, cleaned up the proposed/kilo branches that had no change yet19:41
dhellmannright, the version I ran before had "git review -i stable/kilo" to change the change-id because resubmitting the same change to the different branch failed19:41
dhellmannso I removed the -i and tried again, and it still failed19:41
dhellmannI ran it a couple of times, and it only works with the -i19:41
dhellmannunless I change the commit message some other way, I suppose19:41
dhellmannand, fwiw, I'm not making any changes to the commit by hand19:42
fungiohh... yes you probably need a subtle tweak somewhere to make sure the commit sha is not identical19:42
fungigerrit wants commit sha to be unique between changes and between patchsets19:42
dhellmannk19:42
jeblairor just force a new commit19:42
fungirighth, commit --amend19:42
jeblairi think the timestamps are in the commit sha19:43
fungithey are, right. so is the committer for that matter. both will be updated if you --amend19:43
dhellmannah, and since the rebase isn't actually having to make any changes that's not updating the hash19:44
dhellmannok, so I'll add an amend step19:44
dhellmannI don't suppose there's a way to do that without having to then also exit vi19:44
fungiyou can set EDITOR=/bin/true19:45
fungipretty sure19:45
dhellmannok, I'll try that19:45
ttxjeblair: could we get extra eyes on https://review.openstack.org/#/c/173892/ ?19:45
dhellmannfungi: ok, it looks like that worked: https://review.openstack.org/#/q/Ia563f4130c31baa4dcee3be3786ea3c49b6bad98,n,z19:46
fungiperfect19:47
ttxNow I need to re -2 them19:47
dhellmannttx: I'm going to test one more, then submit all of the rest19:47
ttxdhellmann: looks good19:47
dhellmannhttps://review.openstack.org/#/q/I7b3edf6bf7ea0efaf96398a83dad9ebe61caaa23,n,z19:48
ttxlgtm19:48
dhellmannok, here goes...19:48
AJaeger_dhellmann: git commit --amend --no-edit19:49
dhellmannAJaeger_: aha19:49
fungioh, that sounds a lot more correct than my hack ;)19:49
dhellmannsetting editor to true is also working19:49
ttxsdague: it's a bit uncelar to me why https://review.openstack.org/#/c/173924/ (which is a master change) needs to wait until the branches are right19:50
ttxthat should test master -> master19:50
jeblairttx: what's the membership of foo-stable-maint going to be?19:50
dhellmannhmm, git review seems stuck on this keystone patch19:51
jeblairttx: stable-maint + ptl?19:51
ttxjeblair: it already exists, no ?19:51
ttxIt's specific devs in each projects that sign up to understand and apply stable branch policy. It's been around for the last 5 months19:51
ttx+ stable-maint-core19:52
jeblairttx: what acl references it?19:52
ttxthe corresponding main project19:52
dhellmannah, some of these keystone commits are in series :-/19:52
dhellmannI might have to clean those up by hand19:52
ttxso.. keystone for pycadf python-keystoneclient and keystonemiddleware.19:52
fungilooked like pycadf got their own group there19:53
jeblairttx: got it.  i picked pycadf-stable-maint and noticed it didn't exist19:53
jeblairfungi: ^ yeah19:53
fungibut i'm not looking at the change just now so might be misremembering19:53
ttxoh, the exception that confirms the rule19:53
jeblairso should pycadf use keystone-stable-maint?19:53
fungiso that one might be a bug19:53
ttxjeblair: I'd say yes unless they have a specific stable team19:53
ttxthe goal is not to create any new group19:54
ttxso you may have spotted an issue19:54
mesteryttx: Have a release question for you when you have a moment19:54
jeblairk.  lemme finish reviewing before we address it.19:54
ttxmestery: you may wait forever19:54
mesteryttx: :(19:54
ttxmestery: you should ask withou waiting for me to have a moment19:55
mesteryttx: Ack19:55
mesteryttx: So, we found an issue with the *aaS repos. We need to pin their neutron requirements in requirements.txt and tox.ini, see here for example: https://github.com/openstack/neutron-vpnaas/blob/master/tox.ini#L1319:55
mesteryttx: I'm thinking we need to pin them to @stable/kilo, thoughts?19:55
mesteryttx: Pin to a branch I mean19:55
mesteryttx: My question is, if I'm right, would I send those patches to proposed/kilo in each repo?19:56
ttxmestery: stable sounds good -- especially with the change we are doing now19:56
ttxwe are getting rid of proposed/kilo and switch to stable/kilo directly19:56
mesteryttx: Ack, so I'll just propose a straight-up change to proposed/kilo then?19:56
mesteryttx: OK, so I'll propose them directly to stable/kilo then19:56
mesteryttx: Thanks!19:56
ttxmestery: yes and we'll include them in RC219:56
mesteryttx: Ack, thanks!19:57
ttxI'll -2 them until RC2 window is open19:57
mesteryttx: Cool19:57
mesteryttx: Well, I'll -2 them,.19:57
mesteryttx: One other thing: I sent some cherry-picks to proposed/kilo, shoudl I redo those to stable/kilo?19:57
mesterySorry for the confusion :(19:57
jeblairttx: okay, so pycadf is the only possible error like that i saw, but there are also cases where we're using the -milestone group instead of -stable-maint (but in those cases -stable-maint does not exist yet)19:57
ttxmestery: dhellmann is reproposing them for you19:57
* mestery sends dhellmann a ^519:57
mesterythanks ttx and dhellmann!19:58
jeblairttx: also, there's at least one that's just stable-maint-core... not sure about that19:58
ttxjeblair: yes, because that is what they used there (mostly incubated projects that are not under stable-maint regime yet)19:58
ttx+ stable-maint-core when nothing else ever existed19:58
jeblairttx: should we go ahead and create new groups to make it consistent?  or do you want to keep it that way?19:58
ttxI need to talk to the affected projects to see what they want to do19:58
jeblairttx: since it's just groups, it would probably be easy to add stable-maint-core later19:58
ttxso I'd rather fall back to stable-maint-core in the mean time19:59
dhellmannttx: I'm going to simply abandon the requirements updates from https://review.openstack.org/#/q/status:open+branch:proposed/kilo,n,z19:59
ttxIt's fie to keep it that way for the time being19:59
ttxfine*19:59
ttxdhellmann: ok19:59
dhellmannwe'll get new patches to replace those when we update the global list in that branch19:59
ttxagreed19:59
ttxaaah20:01
ttxdims: please do not approve stable/kilko stuff20:01
ttxsee what I mean with strict ACLs20:01
ttxthe probelm is.. people think they can do things with stable/*20:01
fungiyep. i'm almost done with the acl change proposal. just linting it now20:01
ttxI hate to be right20:01
ttxsigh20:01
ttxยง/me -2s20:02
dimsttx: you mean the stuff from the bot?20:02
ttxI mean anything20:02
ttxin stable/kilo20:02
mesteryyikes20:03
dimsttx: ack. i thought that was posted by the bot by design! apologies20:04
AJaeger_dims, can you remove your +A?20:05
ttxSo, another drawback of using stable/kilo.... it becomes harder to see what things I need to -2 since libs can land stuff there without a RC window opened20:05
dimsAJaeger_: yes, of course20:06
ttxusing proposed/kilo was neatly separating it out20:06
ttxjeblair: You'll hear me rumble forever20:06
fungihttps://review.openstack.org/174074 is the stable/kilo temporary acl addition20:07
fungiit's a union of the refs/heads/proposed/* acl from all-projects (which we can now drop) and the refs/heads/proposed/* additions which some of those projects had in place already20:08
dhellmannttx: I'm updating a few by hand that were in series. Please -2 https://review.openstack.org/#/c/174075/20:09
dimsttx, fungi: do we need stop the job from proposing the requirements update?20:10
ttxdims: I /think/ it will fail now that I -2ed it20:10
fungidims: i don't think so, no. we just need to stop anyone from approving any changes to stable/kilo branches until 174074 lands and has a few minutes to get applied20:11
fungiat least for projects whose acls are changing in that patch20:11
dimsttx, fungi: thanks20:11
dhellmannttx: another: https://review.openstack.org/17407820:14
dhellmannttx: last one: https://review.openstack.org/17407920:14
ttxfungi: acl change looks good20:14
dhellmannttx: all patches have been resubmitted20:15
ttxarh the 10pm network lag hits again20:17
ttxdhellmann: ok, abandoning remaining proposed/kilo branches20:17
dhellmannfungi: I've updated the acl patch based on jeblair's feedback: https://review.openstack.org/#/c/173892/20:18
fungithanks, revisiting20:19
dhellmannI guess we have several acl patches in play now, don't we20:19
fungidhellmann: got it. so going with stable-maint-core rather than keystone-stable-maint there20:19
ttxOK I think I got rid of all of them20:20
fungidhellmann: yes, though if we're lucky, they're all touching a non-overlapping fileset20:20
ttxjeblair: please rereview https://review.openstack.org/#/c/173892/20:20
ttxand approve at will20:20
dhellmannfungi: for pycadf? yeah, using the non-exclusive trick you showed me20:21
dhellmannI guess I could have used pycadf-release there20:21
dhellmannexcept for that team the release group is the folks who push tags, so that's not really the same thing20:21
ttxyeah, we can adjust as needed after20:22
fungiyeah, makes sense. this isn't set in stone. acls are maleable20:22
dhellmannyeah20:22
ttxfungi: ok, we are now blocked by the two ACL changes20:23
ttxhttps://review.openstack.org/#/c/173892/20:23
ttxhttps://review.openstack.org/#/c/174074/20:23
ttxthen we should be able to proceed20:24
ttxsdague: any specific change we should recheck to verify that everythign is now squared ?20:25
ttxhttps://review.openstack.org/#/c/173842/ maybe20:25
dhellmannttx: I rechecked https://review.openstack.org/#/c/173842 to give us fresh results. It would be good to look at a patch against a regular project, too20:27
ttxyeah20:28
ttxwell those things you just proposed should do taht20:28
dhellmannyeah, so the first one that finishes...20:28
ttxdhellmann: so I have a very early train tomorrow so I won't stay up very late20:28
ttxlet's see what more you could push today20:28
dhellmannttx: I'll baby sit these for a while tonight. I'm headed into the city myself tomorrow, so I'll check in first thing and then when I get there20:29
ttxif you can get 6. and 7.2 approved, you can probably do...20:29
*** AJaeger_ has quit IRC20:29
ttx7.320:29
ttx8.1 I am not even sure we need to wait to approve20:30
ttxand even 9.20:30
ttxIf you can get that all pushed I can pick up tomorrow and announce depfreeze end20:30
dhellmannok20:31
ttxdo you se any reason for us to wait on 8.1 ? https://review.openstack.org/17392420:31
ttxI'll recheck it20:31
dhellmannno, that shouldn't affect us, unless we're just being extra cautious20:32
dhellmannsdague tends to see issues with these cross-branch things that I don't, though, and I don't think it will hurt us to wait on that one a bit20:32
ttxhe removed his -2 so I suspect if it passes tests it's golden20:32
dhellmannk20:32
ttxI'll +1 all the stable/kilo .gitreview bumps so taht you can +2/APPRV them once the ACL is fixed20:33
ttxwithout feeling too much like you're self-approving :)20:33
dhellmannttx: ok20:34
ttxok, all +1ed and rechecked the -1s to get fresher results20:40
ttxdhellmann: anything else you need from me ?20:40
dhellmannttx: I think we're good. Get some sleep, and safe travels tomorrow.20:43
ttxdhellmann: ok, I'll connect from the train. Cheers and thanks again!20:44
sdaguedhellmann: yeh, I -2ed that after the test issues I saw20:46
dhellmannsdague: ok, I hadn't seen that the tests failed (busy on other changes) so I wasn't sure what was up20:47
sdaguewell, not fail20:47
sdaguebut the fact that the other requirements thing wasn't doing the right thing20:48
dhellmannoh, yeah, that20:48
dhellmannttx: when you have time, could you take a look at https://review.openstack.org/#/c/173075/ and give your +1/-1? no rush, but it'll make stable management for oslo simpler21:16
dhellmannnow that https://review.openstack.org/#/c/174074/ is approved and we're safe, I'm going to grab dinner. I'll look in on the other blocking changes from https://etherpad.openstack.org/p/the-big-thaw first thing tomorrow21:19
*** dims_ has joined #openstack-relmgr-office21:46
*** dims has quit IRC21:48
*** mestery_ has joined #openstack-relmgr-office23:33
*** mestery has quit IRC23:39

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!