Tuesday, 2014-06-17

ttxnotmyname: We can do 13:45 UTC, that should be 6:45am if my calculation is correct07:00
mikalttx: we're on in about 15 minutes?07:47
ttxmikal: yes07:49
ttx11min07:49
* ttx grabs coffee07:50
* mikal grabs wine07:52
mikaljohnthetubaguy: ^-- grab a drink07:52
ttx#startmeeting ptl_sync08:00
openstackttx: Error: Can't start another meeting, one is in progress.  Use #endmeeting first.08:00
ttxuh08:00
ttx#endmeeting08:00
openstackMeeting ended Tue Jun 17 08:00:29 2014 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)08:00
openstackMinutes:        http://eavesdrop.openstack.org/meetings/incub_sync/2014/incub_sync.2014-06-12-15.29.html08:00
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/incub_sync/2014/incub_sync.2014-06-12-15.29.txt08:00
openstackLog:            http://eavesdrop.openstack.org/meetings/incub_sync/2014/incub_sync.2014-06-12-15.29.log.html08:00
ttxoops.08:00
ttx#startmeeting ptl_sync08:00
openstackMeeting started Tue Jun 17 08:00:37 2014 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.08:00
mikalHeh08:00
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.08:00
openstackThe meeting name has been set to 'ptl_sync'08:00
ttx#topic Nova08:00
mikalHello08:00
ttxmikal: yay, I didn't forget this time.08:01
mikalNeither did I08:01
mikalIts like a personal best for the both of us08:01
ttx#link https://launchpad.net/nova/+milestone/juno-208:01
ttxAs it stands it looks quite good, but i suspect the autokick script has been busy keeping crap entries out08:04
ttxmikal: how.. representative is it of what you expect to land during the next 5 weeks ?08:04
ttxI certainly like that most of those show up as "under review" already08:04
mikalSo, there's a pleasing amount of "needs code review" there08:05
mikalWe do need to start reviewing specs more actively again though, there's a lot blocked up in that process08:05
mikalAlthough, review bandwidth is our obvious problem once again08:05
mikalIts a little hard to tell08:05
* johnthetubaguy waves08:06
mikalI agree that needs code review is good, although it remains to be seen if that's all the code for each of those bps08:06
*** sdague has quit IRC08:16
*** morganfainberg has quit IRC08:16
*** kgriffs|afk has quit IRC08:16
*** dolphm has quit IRC08:16
*** stevebaker has quit IRC08:16
*** jgriffith has quit IRC08:16
*** notmyname has quit IRC08:16
*** ttx has quit IRC08:16
*** mattoliverau has quit IRC08:16
*** johnthetubaguy has quit IRC08:16
*** dhellmann has quit IRC08:16
*** anteaya has quit IRC08:16
*** zaneb has quit IRC08:16
*** devananda has quit IRC08:16
*** ChanServ has quit IRC08:16
*** dansmith has quit IRC08:16
*** SergeyLukjanov has quit IRC08:17
*** mikal has quit IRC08:17
*** dhellmann has joined #openstack-relmgr-office08:21
*** zaneb has joined #openstack-relmgr-office08:21
*** mattoliverau has joined #openstack-relmgr-office08:21
*** johnthetubaguy has joined #openstack-relmgr-office08:21
*** devananda has joined #openstack-relmgr-office08:21
*** anteaya has joined #openstack-relmgr-office08:21
*** mikal has joined #openstack-relmgr-office08:21
*** dansmith has joined #openstack-relmgr-office08:21
*** ChanServ has joined #openstack-relmgr-office08:21
*** SergeyLukjanov has joined #openstack-relmgr-office08:21
*** dickson.freenode.net sets mode: +o ChanServ08:21
*** sdague has joined #openstack-relmgr-office08:22
*** kgriffs|afk has joined #openstack-relmgr-office08:22
*** dolphm has joined #openstack-relmgr-office08:22
*** stevebaker has joined #openstack-relmgr-office08:22
*** jgriffith has joined #openstack-relmgr-office08:22
*** notmyname has joined #openstack-relmgr-office08:22
*** ttx has joined #openstack-relmgr-office08:22
mikalYeah, in some cases its pretty obvious why they're taking a break08:22
*** morganfainberg has joined #openstack-relmgr-office08:22
mikalIs that an unsplit?08:22
mikalttx: we decided you're doing all of nova08:22
johnthetubaguymikal: maybe, I think we just joined back with the rest of the world08:22
mikalttx: you there?08:22
* ttx emerges from the other side of the netsplit08:23
mikalHeh, we had a nice meeting without you08:23
ttxmikal: yt?08:23
mikalBasically we're code talking review backlog and spec review backlog08:23
mikaltalking code even08:23
mikalttx: can you hear me?08:23
ttxo/08:24
mikalHi!08:24
ttxSo I was saying...08:24
ttx<mikal> I agree that needs code review is good, although it remains to be seen if that's all the code for each of those bps08:24
ttx<ttx> it should be. If it's just that intermediary code is in review, it should be set to Good progress08:24
ttx<ttx> Basically "needs code review" means "all code is now up for review"08:24
ttx<ttx> otherwise you keep going back to good progress and it's a bit useless as a progress marker08:24
johnthetubaguymikal: so, we might want to try little blueprints without specs at somepoint soon, but lets just see how its going08:24
ttx<ttx> mikal: how do you want to address that?08:24
ttx<ttx> I was pretty sure that adding a formal spec approval would just make the pipe longer, not faster08:24
ttx<ttx> since the same resources are used in both reviews08:24
ttx<ttx> At the start it will trigger a slowdown as people adjust to the new shape of the tube08:24
ttx<ttx> In the end it should be slightly faster since you should spend less time reviewing the whole idea at code review time08:24
ttx<ttx> mikal: Do you think a specific "spec review day" at the start of a milestone would help fast-approving a pack of them ?08:24
mikalOh, a spec review day is an interesting idea08:25
ttxI think it would give a fast feedback loop08:25
mikalAlthough to be honest I think our biggest problem is we rely on a small number of very busy people08:25
johnthetubaguyah, cool, we spoke about a spec proposal freeze for Juno-2 and Juno-3 on 3rd July08:25
ttxyou could ask BP proposers to handg out08:25
mikalI think the idea of a spec review day should be included in the spec proposal freeze announcement08:26
mikalAnd having a faster feedback loop sounds good to me08:26
johnthetubaguyA combination sounds good08:26
ttxmikal: it's not a magic bullet, but I think having multiple people fast-iterating on them could help fast-approving a few08:26
johnthetubaguypeople often catch me on IRC, and it does help resolve things quicker08:26
mikalI think we also need to remind -drivers to be reviewing specs08:26
mikalI know I haven't been doing enough of it08:26
ttxmikal: it's a bit tricky to prioritize. Been struggling with it myself08:27
johnthetubaguymikal: we did stop doing it that last few weeks on purpose08:27
ttxI guess we'll get used to it08:27
mikalI think its the "very busy person" problem to be honest08:27
ttxmikal: OK, that's all I had. j2 status looks in sync with what you know of today , which is good08:27
johnthetubaguymikal: that was the Juno-1 push, but yeah, we need to get back on the wagon with that stuff08:27
mikalBut anyways, yes. We should refocus on specs for a while and then freeze new proposals08:28
johnthetubaguyyeah, my only worry is the stuff we want that is not yet through spec reviews, so not on the lp radar yet really08:28
johnthetubaguybut the freeze date, and a review day should help that08:28
ttxmikal: e might need to be a bit less strict in spec review approval. There might be a middle ground between "no spec review at all" and "spend 72 patchsets for every spec"08:28
mikaljohnthetubaguy: do you think it would help if we pulled out a list of stuff we really want from -specs and ask drivers to focus on it?08:28
johnthetubaguyttx: +1 I think the little guys need to get through faster08:29
ttxjust having the doc around at code review time is useful08:29
johnthetubaguymikal: I plan to create that as part of the priority setting08:29
mikalI agree that we don't need absolute perfection in specs08:29
ttxso in theory even if we accepted them all directly it would be better than what we were doing with BPs08:29
mikalttx: agreed08:29
ttxso I wouldn't nitpick them to death08:29
ttxOK, I need to run08:29
ttxAnything you wanted to discuss at meeting later/tomorrow ?08:30
mikalNo, I think I am good08:30
mikaljohnthetubaguy: thanks for being awesome once again08:30
johnthetubaguy:)08:31
johnthetubaguyno problem08:31
ttxOK then, ttyl08:31
mikalLaters08:31
mikaljohnthetubaguy: I'm going to wander off to cook dinner, talk more later08:31
johnthetubaguymikal: sounds good, enjoy dinner08:31
johnthetubaguymikal: thinking June 26th for spec review day08:31
mikalWhat day of the week is that?08:32
mikalI'd avoid Mondays and Fridays08:32
johnthetubaguyrelease day, so thursday I think08:32
mikalSounds good to me08:32
johnthetubaguycool, gives a week for loose ends08:32
mikalWorks for me08:33
*** sdague has quit IRC08:33
*** kgriffs|afk has quit IRC08:33
*** dolphm has quit IRC08:33
*** stevebaker has quit IRC08:33
*** jgriffith has quit IRC08:33
*** notmyname has quit IRC08:33
*** ttx has quit IRC08:33
mikalOk, dinner time for me08:33
mikalBye!08:33
johnthetubaguybye08:34
johnthetubaguyseems internet broke again anyways08:34
*** johnthetubaguy has quit IRC08:35
*** johnthetubaguy has joined #openstack-relmgr-office08:36
*** stevebaker has joined #openstack-relmgr-office08:43
*** jgriffith has joined #openstack-relmgr-office08:43
*** notmyname has joined #openstack-relmgr-office08:43
*** ttx has joined #openstack-relmgr-office08:43
*** dolphm has joined #openstack-relmgr-office08:43
*** kgriffs|afk has joined #openstack-relmgr-office08:43
*** sdague has joined #openstack-relmgr-office08:43
*** eglynn has joined #openstack-relmgr-office10:03
eglynnttx: o/11:44
ttxeglynn: o.11:44
ttx#topic Ceilometer11:44
eglynnhey11:45
ttx#link https://launchpad.net/ceilometer/+milestone/juno-211:45
eglynnso almost everything we bumped from juno-1 has now landed11:45
ttxLooks good, if not a bit empty11:45
eglynnyeah the cupboard is still relatively bare for j211:45
eglynnas planning is still in progress11:45
eglynnfiling of BP specs discussed at last week's upstream meeting11:45
ttxThere might have been a few things that got autokicked that you might want to push back in11:46
eglynncool enough I'll check that11:46
ttxThe trick with the new system is that some features may just land without appearing on the release radar at all11:46
eglynnyeah I'll keep an eye on that11:46
ttxso it's good to check that most major ones are accounted for11:46
eglynnBTW we've a long laundry list of possible work items for j2, so no shortage of possibilities11:47
eglynnwe have a few in-flight specs reviews ...11:47
eglynnhttps://review.openstack.org/#/q/status:open+project:openstack/ceilometer-specs,n,z11:47
eglynnbut I'm expecting a lot more by EoW11:47
ttxindeed11:47
eglynnBTW we've had persistent gate problems the past few days with a timing issue in the py26 build11:47
ttxI'd like us to look into the gap coverage plan and progress there11:48
eglynnI've curated the wiki page a bit11:48
ttxhttps://wiki.openstack.org/wiki/Governance/TechnicalCommittee/Ceilometer_Gap_Coverage11:48
eglynn#link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee/Ceilometer_Gap_Coverage11:48
eglynnyeap11:48
eglynnshould be good for review I think11:48
ttxI think you're in good shape there11:48
eglynnshould I plan to be on-hand during the TC meeting this evening for this topic?11:48
ttxNo, I can report back11:48
eglynncool enough11:49
ttxI mean, you can come, of course11:49
ttxbut I'll report back on progress11:49
eglynnthe progress reported on the wiki is up-to-date, I've sanity-checked my updates with each of the "drivers"11:49
ttxOK, no significant delay compared to the initial plan, right ?11:50
eglynnnope, good front-loaded progress for juno-1 as agreed with the TC11:50
ttx#info Gap coverage is on track, expected to be finished by j211:50
eglynnand all remaining action is good shape to for juno-211:50
eglynnshape to *land11:50
ttxDo you expect a lot of the -specs might be j2 material ? or more of j3 material ?11:51
eglynnsome will definitely be j2, which is why I'm eager to get that stuff proposed ASAP11:51
ttxagreed.11:51
ttxWe built a backlog when we switched to specs (with people retroactively filing specs for stuff they already worked on)but I suspect this will be less of an issue11:52
ttxas we go on11:52
eglynnthe -specs process is working ok I think, with just some minor compalining about the Kafkaesque bureaucracy ;)11:52
ttxYou're free to place the cursor where it makes the most sense11:53
ttxi.e. only require specs for high-profile changes if that makes more sense11:53
ttxbut having multiple entry points makes the process more complex11:54
ttxso I would rather have a light template for basic stuff and fasttrack them through11:54
eglynnyeap, I'm erring on the side of requiring a spec in general to get folks used to the idea11:54
eglynnbut defo open to fasttracking the non-contraversial/simpler stuff11:54
ttxNot everything should require endless nitpicking and two +211:54
ttxOK, anthing you want to discuss at cross-project meeting tonight ?11:55
eglynnyeap, I've also tried to minimzie spelling/grammar nitpicks for -specs reviews11:55
eglynnnothing specific I guess11:55
ttxOK, questions?11:55
eglynnquick heads-up on the ceilo mid-cycle July 2-4, many of us will be kinda off-grid for those 3 days11:55
eglynn#link https://wiki.openstack.org/wiki/Sprints/ParisJuno2014#Ceilometer11:55
eglynnmid-cycle attendence shaping up OK so far ...11:55
eglynn... at least another two attendees in the pipeline, which would make 7 for ceilo in total11:56
ttxcool11:56
eglynnnot huge, but definitely reaches quorum11:56
eglynnthat's all I got for today ...11:57
ttxok, great ttyl11:57
ttxSergeyLukjanov: around?11:57
SergeyLukjanovttx, yup12:04
SergeyLukjanovttx, sorry, I've been sending documents for visa12:04
ttx#topic Sahara12:04
ttxfun12:04
ttxhttps://launchpad.net/sahara/+milestone/juno-212:05
SergeyLukjanov#link https://launchpad.net/sahara/+milestone/juno-212:05
ttxLooks good, a bit ambitious maybe12:05
SergeyLukjanovttx, it's not final/clean yet12:05
ttxjust evolve it as reality changes12:05
ttxSergeyLukjanov: I wanted to attrct your attention to https://review.openstack.org/#/c/97872/212:06
SergeyLukjanovttx, I think it's already looks liek our plans for j212:06
ttxproposal to require some sort of translations support in integrated projects12:06
ttxIf I'm not mistaken, that would create an instant gap for Sahara12:07
ttxdo you have plans in that area ?12:07
SergeyLukjanovttx, yup, I've seen it, we already have everything needed configred in sahara (babel, scripts, traslation jobs, transifex project and etc.)12:07
SergeyLukjanovttx, the only gap is lack of the _(..) wrapped strings12:07
ttxSergeyLukjanov: ok12:08
SergeyLukjanovttx, last two assignments doesn't complete this work :(12:08
SergeyLukjanovttx, so, it could be prioritized and done in j212:08
ttxOK, just trying to see if that would place you in some impossible spot12:09
ttxbut apparently, not really12:09
ttxHow is the removal of extra repositories going ?12:09
SergeyLukjanovttx, yup, just wrap lines with _12:09
SergeyLukjanovttx, we have tasks to move sample jobs out of it12:10
ttxdashboard move is ready and pending on horizon devs, as we saw last week12:10
ttxwhat about the other two?12:11
SergeyLukjanovttx, and then we'll have only hadoop swift fs in extra, but we're still not sure about the future of it12:11
ttximage-elemnets was merged already ?12:11
SergeyLukjanovttx, nope, we decided to keep it as is12:11
SergeyLukjanovttx, I was thinking that we already discuss it with you several weeks ago...12:12
ttxyes, certainly :)12:12
ttxi just need to remember12:12
ttxSo in the end, only -dashboard will get merged12:12
SergeyLukjanovso, summary status: keep -image-elements as is, merge -dashboard to horizon, keep only hadoop swift fs in -extra (no releases)12:13
ttxok, so the only risk is with -image-elements ... IIRC you said that it had to be in sync with the release12:13
SergeyLukjanovttx, we're thinking about moving hadoop swift fs to separated repo but we're now in the progress of endless discussions12:14
ttxso having it outside the release management but still kept in sync with official releases sounds a bit brittle to me12:14
SergeyLukjanovttx, we'll push the same tags to it and we'll have docs about buidling corresponding images12:14
SergeyLukjanovttx, and we're planning to publish a base set of images for each release12:14
ttxcan the main software work without the corresponding image-elements ?12:15
SergeyLukjanovttx, yup, if you have correctly prepared image (with installed hadoop)12:15
ttxi.e. can we put ourselves in a strange corner if for some reason we publish one without the other ?12:15
SergeyLukjanovttx, and for some plugins you just need the centos image w/o any preparations12:15
ttxbecause today you're around and I trust you to be around when we'll need to push -image-elements12:16
ttxbut we need to plan for the worst and make sure that the integrated release can continue to work even if you lose interest in release management12:16
SergeyLukjanovttx, it's fair12:17
ttxbut then, if the image-elements can be rebuilt from instructions that are provided with the main software...12:17
SergeyLukjanovttx, in fact we need tag in -image-elements just to mark the version of scripts12:18
dhellmannttx: I'm ready when you are12:18
ttxI guess that's less of an issue12:18
ttxSergeyLukjanov: could you remind me why they can't be put in sahara itself ? It's a size issue, right ?12:18
ttxSergeyLukjanov: I think it's fine to ship separately as long as they can be regenerated from a script that we ship in sahara itself12:19
ttxwe clos ethe loophole then12:19
ttxdhellmann: o/12:19
dhellmanno/12:19
SergeyLukjanovttx, it was very long discussions with tons of pros and cons and eventually the pros number for keeping it as is were much bigger than others12:20
ttxSergeyLukjanov: ok, we'll talk again about it -- I just want to make sure the integrated release is self-sufficient12:20
ttxand not depending on something that nobody knows how to release12:20
ttxexcept you :)12:20
SergeyLukjanovttx, yup, I got your point, I'll take a look on how could we couple sahara integrated release to -image-elements12:21
ttxSergeyLukjanov: did you have a topic for today's meeting?12:21
SergeyLukjanovttx, I'm just pushing the tag to the repo :)12:21
SergeyLukjanovttx, I think no topics from my side for today12:21
ttxack12:21
SergeyLukjanovttx, thank you12:21
ttx#topic Oslo12:22
ttxdhellmann: sorry for the lateness12:22
ttxhttps://launchpad.net/oslo/+milestone/juno-212:22
dhellmannttx: no problem12:23
ttxdhellmann: Looks good, expecting a lot more to emerge from -specs, or mostly complete ?12:23
dhellmannwe're a little slow approving our specs, but I think we have the process down now12:23
dhellmannI have a list of a few of them to propose we accept at the meeting friday12:23
ttxdhellmann: which makes me thing we need to decide on that rootwrap spec12:23
ttxthink*12:24
dhellmannthere are 2 rootwrap specs, do you mean the daemon mode one?12:24
ttxtthe daemon one is not ready12:24
ttxthe ionice one I think is good to go as long as the doc clearly expresses the security tradeoff12:25
ttxbut that's slightly off-topic12:25
dhellmannit looks like there has been an update on that one since you left your request12:25
ttxdhellmann: yes, probably just waiting on me12:25
dhellmannalthough there's a promise of more detail to come, as well, so that makes me think it's not done12:25
ttxhttps://launchpad.net/oslo.messaging/+milestone/juno-212:25
dhellmannoh, no, that's "in the" implementation not "on the"12:26
ttxsame, looks good, if not a bit empty12:26
ttxlike i said earlier, with autokick removing stuff, we need to make sure no major feature flies under the release radar12:26
ttxsince we can't really rely on people adding them back to the milestone page anymore12:27
ttxthat's the downside of this approach12:27
dhellmannyeah, I'll make sure as specs are approved their bps are updated with priority and target12:27
ttxso.. would you say that the current state of the j2 pages shows 50% of what will finally get done ? 75% ?12:28
dhellmannit is about 50% of what we said we would do, but we combined a few libraries so it may be closer to 75%12:29
dhellmannsome of the specs we have up for review weren't discussed at the summit, and some may not be approved12:29
ttxNo, I mean... not compared to summit plans. Do you think you'll add a lot of extra BPs to match late-approved specs, or not that much ?12:30
dhellmannI expect to approve 3 more this week12:30
ttxok12:30
dhellmannoh, yeah, we have a lot of specs that I expect to approve12:30
ttxand those may still fall in j2, right12:31
dhellmannlike I said, we got a late start on that12:31
dhellmanna few, yes12:31
dhellmannthe 3 certainly12:31
ttxok12:31
dhellmannanything we approve for j3 will be a library we don't expect anyone to use this cycle12:31
ttxok12:31
dhellmannI want to keep pushing ahead, so they are ready to be adopted early in k12:31
ttxAnything you'd like to discuss at meeting today ?12:32
dhellmannI have 4 alpha releases planned for early next week12:32
dhellmannall are for libraries already in requirements, but I thought it would be good to give everyone a heads-up that they are coming12:32
ttxdoes that mean that existing libs should have their juno features nailed by j-2 ?12:32
dhellmannI'll tag them early monday, unless someone objects in the oslo meeting friday12:32
dhellmannthat's a good question12:33
ttxIt would kind of make sense overall12:33
ttxif you expect consumers to use those new features...12:33
dhellmannI'd like that. I'm not sure if I would cut anyone off, given the fact that we're always running a little ahead of the rest of the project.12:33
dhellmannmajor features I could see holding12:34
ttx#info Ideally, existing libraries should have their Juno featureset completed by j212:34
ttxOK, thats all I had12:35
ttxanything on your side ?12:35
dhellmann#info alpha releases of stevedore, oslo.config, oslotest, and oslosphinx planned for 23 June12:35
dhellmannno, that's it12:35
ttxcool! thx12:35
ttxttyl12:35
dhellmannthanks!12:35
ttxnotmyname: as noted earlier, you can go at 13:45 UTC if you're interested. that's in 70min?12:36
notmynamettx: my alarm just went off. 13:45 (ie 6:45am pacific) is good with me13:02
*** jpich has joined #openstack-relmgr-office13:44
ttxnotmyname: o/13:45
notmynamettx: hello13:46
ttx#topic Swift13:46
ttxnotmyname: how are you doing ?13:46
notmynamettx: thanks for being flexible with the time13:46
notmynamettx: I'm mostly ok. surgery recovery is going pretty well so far :-)13:46
notmynamettx: I have the goal of merging storage policy patches today. reviews seem to be looking pretty good, and I'm hopeful that with today's time we can get it done13:47
ttxnotmyname: ok, you might want to push those security fixes in as well13:48
ttxthe VMT will just do a public OSSA once the patch is public13:48
notmynamettx: right. I expect those to be included as well. I've been working with tristanC on the right time13:48
notmynamettx: ah ok13:48
notmynamettx: so then it looks like I should be able to do that this afternoon13:49
ttxthere might be a few hours gap but I don't think that's critical in this specific case13:49
ttxOK, I'll let tristanC know13:49
ttxso you might have a RC1 SHA ready for tagging by eod ?13:49
ttxfwiw I adjusted tools so that we support 2-step tagging in master for such Swift intermediary releases13:50
notmynamethat's the goal. at least working its way through jenkins13:50
notmynameok13:50
notmynamettx: meaning that we can do an RC tag and then a final13:50
notmyname?13:50
ttxhttps://review.openstack.org/#/c/99892/13:50
ttxswiftrc.sh pushes a RC1 tag and marks all bugs fixreleased on the final milestone13:51
notmynameok13:51
ttxthen milestone.sh specialcases swift and just tags/uploads tarball without going over bugs again13:51
ttx(at final approval time)13:51
notmynameok13:51
ttxthe only difference with a classic milestone being, we push the RC1 tag and mark bugs fixreleased earlier13:52
ttxa sort of lightweight milestone-proposed13:52
notmynameok. I think I follow that13:53
ttxso if all goes well, we have a 2.0 milestone page, we tag 2.0-rc1 on master, push all FixCommitted bugs to FixReleased/2.013:53
ttxthen when you bless it, we tag 2.0 on master, and upload the resulting tarball on that milestone page13:54
notmynameok13:54
ttxIf you need to fix something, we get fancy with a release branch, cut out of the RC1 tag13:54
notmynameok13:55
notmynamethat makes sense13:55
ttxprobably calling it milestone-proposed so that we get back on our feet with infra scripts13:55
ttxbut I shall soon push the patch so that we can call it proposed/*13:55
ttxI think that works.13:56
ttxso I'll wait for your SHA and run swiftrc.sh when I have it13:56
ttxnotmyname: we should probably create the milestone page now13:56
notmynameI will get it to you as soon as I have it13:56
ttxso you can start retroactively target BP to it13:56
notmynameyes. can you create it in LP?13:56
ttx2.0.0 ?13:56
notmynameyes13:57
ttxi'll do it now13:57
notmynamethanks13:57
ttxhttps://launchpad.net/swift/+milestone/2.0.013:57
ttxso the tag would be 2.0.0.rc113:58
notmynameok13:58
ttxnotmyname: anything else you wanted to discuss ?13:58
notmynamenope. that's what I've got13:58
ttxi'll complain about missing blueprints, but we can do that between RC1 and final :)13:58
notmyname:_)13:58
ttxanything you want to add to meeting agenda for today ?13:59
ttx#info Swift 2.0.0.rc1 hopefully today or tomorrow13:59
notmynamenothing specific13:59
ttxnotmyname: ok, cool. Do you get up early because you can't sleep ?13:59
ttxOr some new routine?14:00
ttxdolphm: around?14:00
notmynameunfortunately today the answer is yes. normally its because of kids, though. I'm normally up between 6:30 and 7:00 on most days14:00
ttxnotmyname: ok, get better soon!14:00
notmynamethanks :-)14:00
dolphmttx: o/14:01
ttx#topic Keystone14:01
ttxhttps://launchpad.net/keystone/+milestone/juno-214:02
ttxThat's pretty raw14:02
ttxDo you have more still baking in the -specs repo ?14:02
dolphmjuno-2 will be our first milestone which requires proposals to keystone-specs first14:02
ttxdo you think they will get out of there fast enough ?14:02
ttx(to make j2) ?14:02
dolphmi believe so14:03
dolphmwe have a 5 or 6 that are well rounded at this point14:03
dolphmhttps://review.openstack.org/#/q/project:openstack/keystone-specs,n,z14:03
dolphmlast week we discussed how we want to work the approval process on that repo, which i think we'll finalize today and see a few land14:04
ttxOK well, add them as they are approved, if they still make sense for j2.14:04
ttxI /think/ in the end we'll have a one-milestone delay, like specs that are approved during j1 can be targetted to j214:04
ttx(except low-flying objects obviously)14:05
dolphmi think we were thinking in that direction as well, but we're off to a later start than nova, for example14:05
ttxyes, starting the process will always craete a delay/backlog/mess14:05
ttxOK, so just add them as they are approved14:05
ttxMy script doesn't do miracles yet, since LP doesn't have a blueprint-cration API yet14:06
dolphms/yet// ?14:06
ttxlifless convinced someone to work on that14:06
dolphmoh alrighty then14:06
ttxI think he is embarassed that it sucks so much :)14:07
ttxor surprised.14:07
ttxanyway14:07
ttxi didn't have much in store for you. That autokick script basically makes sure the blueprint page looks good :)14:08
ttxThe trick being, to make sure it contains everything it should14:08
ttxso keep an eye for feature sflying below the radar14:08
ttxand make sure major ones are mentioned in the milestone page... even if they bypassed the spec process somehow14:09
ttxdolphm: anything you wanted to add to today's meeting agenda ?14:09
dolphm#info Support for compressed PKI tokens landed in keystone; we'd like to make them the default in keystone & devstack during Juno14:10
dolphmjust that ^14:10
ttxok, great!14:11
ttxthat's just for #info right, not for a discussion item ?14:11
dolphmi don't believe so; if we suspect we might cause any pain (which i don't think is the case), i'll raise a discussion item14:12
ttxdolphm: ack. ttyl then!14:13
dolphm /salute14:13
ttxjgriffith: ready when you are14:14
*** markmcclain has joined #openstack-relmgr-office14:24
*** mestery has joined #openstack-relmgr-office14:27
ttxjpich: representing david today ?14:33
jpichttx: Yes, if needed!14:33
* ttx doesn't see mrunge around14:33
ttxjpich: you're in!14:33
ttx#topic Horizon14:33
ttxhttps://launchpad.net/horizon/+milestone/juno-214:33
ttxlooks a bit too big and heavily needs prioritization and other improvements, but i'll annoy david with it rather than you14:34
*** mestery has quit IRC14:34
jpichI'm lucky :-) On the plus side a lot of it is up for review14:34
*** mestery has joined #openstack-relmgr-office14:35
ttxjpich: i wanted to go over the Gap coverage plan progress quickly14:35
ttxhttps://wiki.openstack.org/wiki/Governance/TechnicalCommittee/Horizon_Gap_Coverage14:36
jpichOk14:36
ttxLooking at it, only the misison statement is late14:36
ttxis the horizon split still doable within juno-2 ?14:36
jpichI think the mission statement has a proposal in it, not sure if it needs to be vetted before the item can be marked as complete?14:37
jpichrdopieralski is currently doing a lot of work on the split, I think we're still hopeful it'll be doable within juno-214:38
ttxit should be proposed to the governance repo at some point14:38
ttxok14:38
jpichProbably there'll be fresher news during the Horizon meeting later today14:38
ttxwhat about your piece, "Integration Framework Tied to Gate" ?14:38
ttxIs it still on track for j3 ?14:39
jpichThere's several folks currently submitting tests for review so I think it's chugging along nicely14:39
ttxok cool14:40
jpich(we'd agreed with the Tempest folks back in HK to start this in our own repo since the tests will be very different from the API tests)14:40
ttxThat's all I had14:40
jpichnow I don't know when a testing effort can be considered "complete"14:40
ttxyes, agreed14:40
jpichSo there'll be more by Juno-3 for sure :)14:40
jpichI didn't have anything to bring up myself14:40
ttxAnthing you or someone else on the Horizon team wanted to discuss at the cross-project meeting today ?14:41
jpichNot that I'm aware of14:41
ttxjpich: ok, let me know if that changes14:41
jpichOk14:41
ttxjpich: thx for standing in !14:41
jpichNo problems! Cheers14:41
ttxmestery: ready when you are14:41
mesteryttx: o/14:42
ttx#topic Neutron14:42
ttxhttps://launchpad.net/neutron/+milestone/juno-214:42
ttxLooks good14:42
ttxDid most of those go throug the -specs process ?14:43
mesterythanks14:43
mesteryYes, some are not approved and we're working on it14:43
*** markmcclain has quit IRC14:43
mesteryI will bump those not approved over the next week14:43
ttxmestery: wanted to quickly go though the Gap coverage plan, wince I will report progress at the TC meeting today14:43
mesteryttx: Cool, I'm ready!14:43
ttxhttps://wiki.openstack.org/wiki/Governance/TechnicalCommittee/Neutron_Gap_Coverage14:44
mesteryWant me to walk through each item?14:44
mesteryI was going to prepare an etherpad with progress, but traveling for LBaaS this week14:44
ttxyes, quick walkthrough of progress maybe14:45
mesterySo, Gap 0 has a spec ready for approval: https://review.openstack.org/#/c/9573814:45
mesteryWe have converged there, and coding has also started.14:46
ttxok14:46
mesteryGap1: We have 1 API test left to merge, and new scenario tests are being written now (spec is in tempest -specs repo).14:46
mesteryGap2 is being worked at the moment, I need to sync with the developer who's assigned to that this week.14:46
mesteryGap3 has a patch waiting to be merged (Juno-3)14:46
mesteryGap4: There was only one API call which was needed, a WIP patch is out for it.14:47
mesteryGap5: We merged a few DVR patches, and more are being reviewed now. We should be landing the majority of them over the new few weeks.14:47
ttxok, so gap4 is late but it's shallow14:47
mesteryGap4: Correct14:47
mesteryGap6: We have a WIP patch in nova for an API there, and a spec for that should be proposed this week yet on the neutron side.14:47
ttxgap5 should probably be retargeted to j2 then14:48
mesteryGap7: I'll start that later in Juno-2.14:48
mesteryCorrect14:48
ttxfeel free to edit that page14:48
mesterySo, that's a whirlwind update.14:48
mesteryOK, will do14:48
ttxOK, looks like it's taking slightly more time, but still on track14:48
mesteryThat's a fair assessment, yes.14:49
ttxnext on our busy 15-min, i wanted to talk about https://wiki.openstack.org/wiki/Blueprints#Neutron14:49
mesteryOK14:49
ttxThere is something there (and in nova and Oslo instructions) that doesn't work with autokick14:49
ttx"Once your design specification has been committed to neutron-specs: "14:49
ttx"Propose your blueprint, as above, by selecting the milestone in which you plan to complete the blueprint "14:50
mesteryOK, shall I remove that part?14:50
ttxThat will result in them getting punished by autokick14:50
mestery:)14:50
ttxMy proposal is...14:50
ttxwe get rid of the whole "Once your design specification has been committed to neutron-specs: " section14:50
*** markmcclain has joined #openstack-relmgr-office14:50
ttxYou as driver put the BP on the radar by adding milestone and priority14:50
mesteryMakes sense to me.14:51
ttxthen the assignee can update milestone and implementation status to reflect progress14:51
mesteryI've been doing that already anyways. :)14:51
ttxi'll provide a script to do that in one step14:51
ttx(including updating the link)14:51
mesteryOK14:51
ttxso that shoud not be that much of a hassle14:51
ttxAlso would you mind if we collapsed the instructions for Nova/Oslo/Neutron ? they don't seem that much different now14:52
mesteryI am all for that actually, makes perfect sense.14:52
ttxI'm rewriting the page following numerous complains that it advocates a behavior that I seem to punishg14:52
mestery:)14:52
ttxWe'll still ask them to register the blueprint themselves though14:53
ttxeven if that's a bit bureaucratic14:53
ttxit makes them the owner of the spec, which seems right14:53
ttx(err... owner of the Bp)14:53
ttxOK, tat went faster than I thought. That's all I had14:54
mestery:)14:54
mesterySame here, thanks ttx!14:54
ttxanything you want to add to meeting agenda for today ?14:54
mesteryNothing at this time, no.14:54
ttxsince we have a couple more minutes, could you quickly explain what the two essential blueprints are about ?14:54
ttxNeturon Distributed Virtual Router for OVS14:54
*** markmcclain has quit IRC14:55
ttxNeutron DB Migration Refactor14:55
mesteryDVR is the functionality equivalent for nova multi-host14:55
ttxthe first one is the DVR thing that we ask in gap coverage right14:55
ttxok14:55
mesteryRight14:55
mesteryAnd the second one covers Gap014:55
mesteryIt's the spec for how we will move forward with DB migrations in neutron, the healing migration, etc.14:55
ttxOK, that's clear14:55
mesterycool14:55
ttxI could have figured it out by reading them, but since we had one minute left...14:56
mestery;)14:56
* ttx gets lazy with age14:56
* mestery is the same way.14:56
ttxmestery: thanks! ttyl14:56
mesterythanks! Later.14:56
ttxjgriffith: around now ?14:56
jgriffithttx: hola14:58
jgriffithttx: we should probably change my time :(14:58
ttx#topic Cinder14:58
ttxwe should :)14:58
jgriffithttx: I'm driving in to the office more lately14:59
ttxI have 2 minutes, let's be quick14:59
jgriffithttx: and it's screwing up our system14:59
jgriffithk14:59
jgriffithI'm good :)14:59
jgriffithall set :)14:59
ttxhttps://launchpad.net/cinder/+milestone/juno-214:59
ttxhttps://blueprints.launchpad.net/cinder/+spec/task-logging has no assignee ?14:59
jgriffithharlow is working on it14:59
jgriffithI'll update it to reflect correctly14:59
ttxok, you should assign it to him then14:59
ttxok14:59
*** markmcclain has joined #openstack-relmgr-office14:59
ttxOtherwise that's all cinder-specs-approved stuff ? Or there are a few direct adds ?15:00
jgriffithSome are still direct carry overs from the pre-spec days15:00
ttxAre you expecting much more to make it out of cinder-specs in time for j2 ?15:00
jgriffithbut I've been actively swatting those that have come in after15:00
jgriffithttx: I'm hoping for at least two more15:01
ttxok15:01
jgriffithttx: but honestly my prio right now is catch up on what's in the queue15:01
ttxanything you want to add to meeting agenda ?15:01
jgriffithif that doesn't happen I'll just stop accepting new things altogether15:01
jgriffithnope, I"m good thanks15:01
ttxok, talk to you more next week15:01
ttxwe can discuss a better time for you too15:02
jgriffithttx: cool, sorry about that15:02
*** kgriffs|afk is now known as kgriffs15:06
zanebo/15:46
ttxzaneb: o/15:47
ttx#topic Heat15:47
ttxhttps://launchpad.net/heat/+milestone/juno-215:48
zaneblooks like we got through j-1 relatively unscathed :)15:48
ttxThe page looks good, but the autokick script might have been hard at work15:49
zanebI suspect so15:49
zanebooh, I'm gonna move my first one to implemented15:49
ttxzaneb: do you have a lot of work still stranded in -specs approval that you expect will be added here ?15:49
zanebpatches finally merged15:49
*** jpich has left #openstack-relmgr-office15:49
zanebI don't think there's much, if anything, for j-215:50
ttxok15:51
zanebhttps://review.openstack.org/#/q/status:open+project:openstack/heat-specs,n,z15:51
zanebactually, that's a longer list than I thought15:51
* zaneb needs to do more reviews15:51
zanebbut most of it is more long-term15:51
ttxi was wondering... do you ask people to file a blueprint in parallel to filing a spec ?15:51
ttx(like nova/neutron do ?)15:52
zanebno, I haven't been15:52
zaneband we haven't had any approved yet, so it's a bit academic at this point ;)15:52
ttxhah15:53
zanebbut I did have a question about that the other day, w.r.t. a Keystone spec15:53
zanebis it likely that a script will handle this in the future? or should I be encouraging people to create bps as well?15:53
ttxWell the benefit of asking them to file the BP is... they are rightly marked as owning it, and then we can use a script to update all relevant fields at approval time15:54
ttxI planned to ahve a BP-creation script but it's stalled due to lack of BP creation API in Launchpad15:54
ttxso at this point, asking them to create the original BP is not a bad idea15:54
ttxsince THEN you can update all fields via the script i'll be providing :)15:54
zanebok, cool. I'll go with that answer next time ;)15:55
ttxIt just.. feels wrong to ask them to file in two places.15:55
zanebyeah, it does a bit15:55
ttxBut then, their time is more expandable than yours, generally15:55
zanebspecs repo should be _less_ work, ideally15:55
ttxif someone needs to do it manually, better be them15:56
zanebI support that :D15:56
ttxI just rewrote https://wiki.openstack.org/wiki/Blueprints15:56
ttxto account for the new process, autokick script included15:56
zaneboh, nice15:56
zanebso when can we kill launchpad? ;)15:57
ttxWorking on it15:57
ttxzaneb: anything you want to add to meeting agenda for today ?15:58
zanebnope, I'm good15:58
ttxOK then, ttyl15:58
zanebthanks ttx o/15:58
ttxno markwash yet15:58
ttxno Nikhil either. Beer time!15:59
*** markwash has joined #openstack-relmgr-office16:00
ttxmarkwash: o/16:02
markwashhi there16:02
ttx#topic Glance16:02
ttxhttps://launchpad.net/glance/+milestone/juno-216:02
ttxSmall but consistent16:03
ttxmarkwash: do you have a lot queued in -specs ?16:03
markwashyeah, about 7 at this point16:03
ttxAny of them likely to make juno-2 ?16:04
markwashyes, at least one16:04
ttxDo you have a stop date after which you'll stop considering them ?16:04
markwashwe didn't plan on anything like that16:04
ttxok16:04
ttxthat's fine16:04
markwashwe've just been trying to build our glance-specs review momentum so far16:04
ttxmarkwash: i put the "gap coverage plan" on the TC agenda for today -- that's just about how you think you can address the small integartion testing gap that was called out last week16:05
ttxwe can delay it to next week, agenda is busy16:05
markwashyes please, I was going to ask actually16:05
ttxbut it should be 3 lines on a wiki page16:05
markwashoh16:05
ttxmarkwash: OK, that works16:06
ttxyou might want to have a plan first (with an assignee) before you write those 3 lines :)16:06
markwashI think those 3 lines are basically: add more glance tests to tempest in juno-216:06
markwashand then two lines of squiggles :-)16:06
ttxyeah, something like that. With a "task owner" :)16:06
markwashand hearts16:06
markwashokay16:06
ttxmarkwash: your call, we can defer to next week16:07
markwashI asked around for volunteers at last team meeting, but made it sound like people needed to do it immediately and no one had time16:07
markwashyeah, let's do next week16:07
ttximmediately, no. Within juno would be good16:07
ttxok, moving to next meetign agenda16:07
ttxwhat else...16:08
ttxanything you'd like to put on cross-project meeting agenda ?16:09
markwashI need to update the mission statement proposal again16:09
markwashnothing for cross-project from me16:09
ttxyes, we'll talk about it at the TC meeting16:09
ttxso if you have a new version, better post it before16:09
ttxi'l try to ask to cut the nitpikcing16:09
markwashI'll see if I can take a pass, I didn't realize it was on the agenda for this week but I suppose that was very silly16:10
markwashI have to prep for the ptl webinar as well16:10
ttxit's up on the governance change list, so we try to cover it asap16:10
ttxbut as I said, it will be a busy meeting16:10
markwashyeah, that's exactly what I should have expected16:10
ttxso we might just skip it anyway16:10
ttxwe'll see how it goes16:11
markwashthat might also be best, I'll put in an update to the language sometime tomorrow or thursday in any case16:11
ttxThat's all I had. The -specs driven workflow certainly makes it simpler to sync between us.16:11
* ttx hugs autokick.py16:11
markwashhaha16:12
ttxmarkwash: ttyl!16:12
markwashthanks16:12
*** SlickNik has joined #openstack-relmgr-office16:14
ttxSlickNik: o/16:17
SlickNiko/16:17
ttx#topic Trove16:17
ttxhttps://launchpad.net/trove/+milestone/juno-216:17
ttxSlickNik: so you should set a priority for those 4 "undefined" things, if you want to bless them16:17
ttxif not, you should clear their milestone target field so that they don't mess up our view16:18
ttxOtherwise looks good16:18
SlickNikttx: Okay will probably do that today.16:18
SlickNikAlong with bug triage, which I haven't had a chance to do this week, as yet.16:19
SlickNikLot more BPs, and we're making some good progress in juno-2.16:19
ttxwould you say your j-2 plans is accurately representing what you plan to accomplish for j2 ?16:20
SlickNikA couple of them marked not-started have actually begun, so I'll take an action to update the list to better mirror actual progress.16:20
ttxOK, wanted to talk about progress on your gap coverage plan16:21
ttxhttps://wiki.openstack.org/wiki/Governance/TechnicalCommittee/Trove_Gap_Coverage16:21
ttxCould you quickly go through it and tell me about progress, if any ?16:21
SlickNikWe've made really good progress to Concern #1.16:22
SlickNikWe're looking at integration tests right now, and neutron support might actually merge early (in Juno 2).16:22
ttxcool!16:23
SlickNikWe made a bit of progress on the doc front (i.e. updates to the deploy doc), but we still have more work to do here.16:23
SlickNikI'm going to take on some of it, and get a couple of other cores to help.16:24
SlickNikWill try to get a good chunk done in Juno-2, but I suspect we'll probably need to keep working on docs even past that (through Juno 3)16:24
SlickNikFor concern #3: We've got a patch for an experimental job in CI infra out already.16:25
SlickNikOnce that merges, we're going to iron out kinks in it, and look to make it gating.16:25
SlickNikAnd once that happens, we can turn off the old reddwarf-ci16:26
SlickNikReview for the experimental job I mentioned16:26
SlickNik#link https://review.openstack.org/#/c/98517/16:26
SlickNikFor Concern #4, I've been working with amcrn and cp16net and we've been doing a good job on staying on top of triage, and process.16:28
SlickNikSo a couple of main pushes for Juno 2 for us will be around focusing on Concerns #1, and #2.16:29
ttxok16:30
ttxI think we can consider #4 done16:31
ttxit's more of a policy thiung16:31
ttxwhat about #5 ?16:32
SlickNikI alluded to #5 earlier, out of order (sorry!).16:33
SlickNik#link https://review.openstack.org/#/c/88349/16:33
SlickNikIt's close to being done.16:33
SlickNikannashen is debugging a couple of failing tests16:34
SlickNikBut once that's fixed (i.e. the tests are passing) the patch looks in good shape, and we're on track to get that merged for Juno 216:35
ttxoops sorry16:36
ttxparallelizing discussions.16:36
ttxOK so overall, takes more time than expected but still on track for Juno16:37
SlickNikNot a problem. :)16:37
ttxSlickNik: feel free to adjust milestone targets on that wiki page16:37
SlickNikYes, that's a good summary.16:37
ttxSlickNik: i'll report on your behalf to the TC16:37
ttxSlickNik: anything you want to add to meetign agenda for today ?16:37
SlickNikttx: Awesome, thanks. When will the report be? I'll try and be there too, in case anything something comes up.16:38
ttx20:00 utc meeting16:38
ttx(TC meeting)16:39
SlickNikAh, today. sounds good!16:39
SlickNikttx: Nope. I'm trying to push out a client release sometime this week with all the bugfixes we've done for juno-1.16:39
ttx#info trying to push out a client release sometime this week with all the bugfixes we've done for juno-116:39
ttxok then... releasing you. ttyl :)16:40
ttx#endmeeting16:40
openstackMeeting ended Tue Jun 17 16:40:17 2014 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)16:40
openstackMinutes:        http://eavesdrop.openstack.org/meetings/ptl_sync/2014/ptl_sync.2014-06-17-08.00.html16:40
SlickNikThanks much! Catch you later!16:40
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/ptl_sync/2014/ptl_sync.2014-06-17-08.00.txt16:40
openstackLog:            http://eavesdrop.openstack.org/meetings/ptl_sync/2014/ptl_sync.2014-06-17-08.00.log.html16:40
*** mestery_ has joined #openstack-relmgr-office17:05
*** mestery_ has quit IRC17:05
*** mestery_ has joined #openstack-relmgr-office17:06
*** mestery has quit IRC17:07
*** mestery_ is now known as mestery17:07
*** kgriffs is now known as kgriffs|afk17:23
*** kgriffs|afk is now known as kgriffs17:44
*** johnthetubaguy is now known as zz_johnthetubagu17:52
*** kgriffs is now known as kgriffs|afk17:54
*** kgriffs|afk is now known as kgriffs18:07
*** kgriffs is now known as kgriffs|afk18:17
*** eglynn has quit IRC18:43
*** kgriffs|afk is now known as kgriffs19:08
*** kgriffs is now known as kgriffs|afk19:17
*** eglynn has joined #openstack-relmgr-office19:18
*** kgriffs|afk is now known as kgriffs19:24
*** eglynn is now known as eglynn-afk19:51
*** dhellman_ has joined #openstack-relmgr-office20:12
*** sdague has quit IRC20:19
*** kgriffs has quit IRC20:19
*** dolphm has quit IRC20:19
*** stevebaker has quit IRC20:19
*** jgriffith has quit IRC20:19
*** notmyname has quit IRC20:19
*** ttx has quit IRC20:19
*** sdague has joined #openstack-relmgr-office20:20
*** kgriffs has joined #openstack-relmgr-office20:20
*** dolphm has joined #openstack-relmgr-office20:20
*** ttx has joined #openstack-relmgr-office20:20
*** notmyname has joined #openstack-relmgr-office20:20
*** jgriffith has joined #openstack-relmgr-office20:20
*** stevebaker has joined #openstack-relmgr-office20:20
*** eglynn-afk is now known as eglynn20:46
*** dhellman_ has quit IRC21:26
*** morganfainberg has quit IRC21:50
*** morganfainberg has joined #openstack-relmgr-office21:50
*** eglynn has quit IRC22:05
*** zaneb has quit IRC22:36
*** markmcclain has quit IRC22:52
*** markmcclain has joined #openstack-relmgr-office23:00
*** mestery has quit IRC23:06
*** markmcclain has quit IRC23:14

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