09:06:31 #startmeeting ptl_sync 09:06:32 Meeting started Tue Feb 3 09:06:31 2015 UTC and is due to finish in 60 minutes. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 09:06:33 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 09:06:34 #topic Heat 09:06:35 The meeting name has been set to 'ptl_sync' 09:06:41 asalkeld: o/ 09:06:45 hi 09:07:02 #link https://launchpad.net/heat/+milestone/kilo-2 09:07:05 i think it's in ok shape 09:07:21 there are 2 bugs and 2 bps soon to go in 09:07:24 Still have 2 open BPs and 2 open bugs, are we trying to get those in before the tag ? 09:07:42 ttx, just to be clear, the tag is in 2 days? 09:07:49 on the 5th 09:08:05 The tag window is Tuesday-Thursday 09:08:14 so anytime during the window is fine 09:08:17 * ttx checks the Bp<->review mapping 09:08:29 my wed-frid 09:08:42 ttx, i'll keep that in mind 09:08:51 decouple-nested is waiting on the 3 at https://review.openstack.org/#/q/topic:bp/decouple-nested,n,z ? 09:08:52 all those *should* be ok 09:09:06 ttx, yeah i have taken that one over 09:09:18 stack-breakpoint waiting on https://review.openstack.org/#/c/146123/ 09:09:19 if it can't make it, i'll move to k3 09:09:27 breakpoint should be fine 09:09:31 just one patch 09:09:47 bug 1411103 on https://review.openstack.org/#/c/147463/ 09:09:58 1406692 09:10:12 doesn't seem to have areview up yet 09:10:19 is that correct ? 09:10:50 but you just point out the review? 09:11:06 ooo, different numbre 09:11:08 bug 1406692 09:11:33 we can move that one 09:11:41 ok, moving 09:11:43 pushed to k3 09:12:07 OK, that sounds like a reasonable number of things to wait on 09:12:20 cool, i'll try my best to get all that in 09:12:21 I'll track progress against those reviews 09:12:30 and will confirm itr's good to go once they are in 09:12:37 thx! 09:12:46 (and ping you if they obviously won't make it during the tag window) 09:13:10 asalkeld: looks good to me... questions on your side ? 09:13:14 ttx, when you ideally like to tag 09:13:35 so i can gauge when this should be in 09:13:40 I like to tag on my Wednesday morning, your Wednesday evening 09:13:43 utc 09:13:49 ok 09:13:55 but it's fine to do Thursday morning too 09:13:55 that's all godd 09:14:01 I don't like Thursday evening that much 09:14:09 but you should be sleeping then :) 09:14:09 lol 09:14:30 ok, all good from my end 09:14:33 ok, if you don't have other questions, have a good week! 09:14:41 you too 09:15:11 * ttx waits for johnthetubaguy 09:27:55 ttx: hey, sorry for the wait 09:28:25 johnthetubaguy: o/ 09:28:28 #topic Nova 09:28:42 #link https://launchpad.net/nova/+milestone/kilo-2 09:28:44 cool 09:28:57 pretty impressive list of stuff under review here 09:29:37 yeah, its gone a bit mad 09:29:48 people actually got their code up for review, which is nice 09:29:50 johnthetubaguy: what do you expect will happen ? a few of them merge and we defer the others ? 09:30:14 I actually expect to defer all the low ones, that have no patches merged yet 09:30:14 Or do you plan to start pushing back to L ? 09:30:22 yeah 09:30:28 defer to L for those 09:30:34 Would deferring now help in prioritizing reviews, or not so much ? 09:31:13 so, possibly, I was going to check through the list, and see if there are BPs with old −1s on the reviews, etc 09:31:28 I'm a bit concerned with this multi-month feature freeze for non-priority stuff 09:31:53 Historically, feature freeze was relatively well accepted because it's onlt a couple weeks before we open the next dev branch 09:32:10 Will be a harder sell if it's a couple months away 09:32:24 yes, its basically us trying to do the slots things, just only for one sprint 09:32:29 people with those patches will have to rebase against master and keep them in the fridge 09:32:49 just we don't see how we can get the priority stuff merged otherwise 09:33:00 right, not saying you shouldn't do it 09:33:17 just wondering how well that would be accepted, given how many patches fall into that group 09:33:26 yeah, I mean, lets be honest, its a massive experiment 09:33:37 people seemed to agree on the priorities as being important, and bug fixes 09:33:57 A number of them have been asking for exceptions right 09:34:17 yes, but those where mostly the specs we didn't get merged 09:34:25 at least up until this point 09:34:32 hmm, ok 09:35:02 yeah, its madness, we have way more code than we can review at this point, this is our attempt at being honest and telling people its no going to happen 09:35:02 johnthetubaguy: so I guess we should wait as much as we can before we tag 09:35:16 whatever gets in is in 09:35:23 yes, thats fair 09:35:49 how about we have this same discussion on Thursday and see if there is value in waiting a feqw more hours ? 09:35:52 I think, the stuff thats almost, but not quite in, I might let slide into the first week of kilo-3, without too much process, but lets see how it looks I guess 09:36:25 I am good with that, I mean, maybe we catch up tomorrow morning, so see how the burn down is looking? 09:36:44 johnthetubaguy: sounds good 09:37:02 johnthetubaguy: I have been discussing recently the value of milestone targeting... It's a lot of effort to maintain and we consistently miss our predictions 09:37:14 I mean, we spoke about actually aiming for zero exceptions this time, possibly over-roating though 09:37:33 yes, that came up at the midcycle actually 09:37:46 johnthetubaguy: we could technically take the linux approach and not even try to predict. Just collect whatever is landed 09:37:55 can't say we had any great ideas, yeah, thats the only one that came up 09:38:26 The milestone is still useful as a reference date, the tag is still useful as a way to exercise the machinery 09:38:37 but as a promise, it's not that great 09:39:04 johnthetubaguy: and not having to maintain it would free us to do more useful things 09:39:12 like focus on priority tasks 09:39:14 very true, I am keen on the idea 09:39:30 I guess we have to try it to know how it looks 09:39:55 I will think about it a bit more... and probably start a thread on the ML 09:39:57 we should be able to have tooling to automatically fill in the milestone after we tag, I guess 09:40:07 I know some projects are attached to producing meaningful milestones 09:40:23 the milestone in LP always had two meanings 09:40:23 ttx: appreciated, it should make things more scalable 09:40:32 the promise and the actual delivery 09:40:38 using the same damn field 09:40:40 ah, thats true 09:40:46 which causes all sort of pain 09:40:56 The delivery is still very useful 09:41:04 yeah, we sorta stopped bothering with the promise, mostly, without telling people 09:41:11 yeah, if we can automate that, then awesome :) 09:41:19 collecting what was merged when we tag and add it as a delivery milestone to the bug, very good 09:41:49 using a single list of things to track, not so good 09:42:01 that tension shows in how we use those milestone pages 09:42:03 yeah 09:42:15 sometimes those are targets of opprtunity, sometimes those are milestone tag blockers 09:42:33 and then suddenly we purge it and it becomes the list of stuff actually landed 09:42:47 priority is better for, this should go in first, then defer it if its too late for this release 09:43:01 (fwiw in storyboard we don't really replicate the concept of "promised milestone") 09:43:18 yeah, thats a good way of talking about the problem, not thought about it as clearly as that before 09:43:21 (and you should be able to use multiple "priority lists" to track random stuff) 09:43:37 one could be milestone blockers, another could be targets of opportunity etc) 09:43:58 Targeting tasks against a future milestone is still useful for RC tracking 09:44:14 thats true 09:44:16 but that's actaully the exception rather than the rule 09:44:20 yeah 09:44:29 anyway, random thoughts 09:44:33 I mean the discussion we had before was interesting 09:44:36 just wanted to check where you stood on that 09:44:44 feature freeze time, we are really good at merging things 09:44:50 because we have a smaller list to focus on 09:45:15 so keeping that, maybe using priorities, sounds good 09:45:37 ignoring milestones, for want of a better word, should free up more time to set priorities better, etc 09:45:50 johnthetubaguy: identifying those BPs which are 99% there could be a useful way to prioritize reviews 09:46:05 (for k2) 09:46:08 yeah, I think I am going to go do that 09:46:25 because those 99% there won't take a two-months wait that gracefully 09:46:26 this stuff has some +2s, lets finish it off, etc 09:46:31 agreed 09:46:39 even if it's Low. 09:47:05 yeah, that makes them more angry, honestly 09:47:30 so yes, identifying a few things that could easily make it with some focus could help 09:47:55 alright, I'll talk to you later this week as we approach the fatidic tag 09:49:06 johnthetubaguy: did you have any question ? 09:49:20 ttx: I am good, thanks for your help 09:49:29 looking forward to the thoughts on milestones 09:49:50 johnthetubaguy: ack, have a good day! 09:50:24 any you! 09:50:26 ops 09:50:28 and you! 13:00:05 eglynn: around? 13:00:50 ttx: hey 13:00:52 #topic Ceilometer 13:00:55 eglynn: hi! 13:01:03 #link https://launchpad.net/ceilometer/+milestone/kilo-2 13:01:12 #link https://launchpad.net/ceilometer/+milestone/kilo-2 13:01:21 I see 4 BPs and one bug. 13:01:29 I've already bumped the BP that won't make it 13:01:30 All things you'd like to wait on before we tag ? 13:01:45 the others are likely to hand later today or early tmrw 13:01:51 *land 13:01:59 checking blocking reviews 13:02:01 just minor nits in tests etc. 13:02:18 disk-info-meters pending on https://review.openstack.org/#/c/145819/ 13:02:42 yeap, that's the only one I'm slightly concerned about 13:02:43 hyper-v-disk-latency-metrics pending on .. ? all merged? 13:03:14 a-ha yes, updating status 13:03:17 declarative-http-tests pending on https://review.openstack.org/#/c/146187/ 13:03:44 yep, cdent is working on the last test nit as we speak 13:04:01 elasticsearch-driver pending on ... https://review.openstack.org/#/c/137131/ ? 13:04:16 yep gordc will be online soon to get that over the line today 13:04:39 can't find the change in Gerrit for https://bugs.launchpad.net/ceilometer/+bug/1403787 13:05:15 darn, I mean to bump that 13:05:16 Also ceilometermiddleware is marked completed but https://review.openstack.org/#/c/151744/ is still in flight 13:05:18 done now 13:06:05 should it be reverted to NeedsCodeReview? 13:07:01 yeap, we were looking that just now ... I've +A'd the patch 13:07:34 ok, let's mark it NeedsCodeReview until patch makes it ? 13:08:21 ok, done 13:08:25 OK, so I'll keep track of those last things and ping you when I think we can tag. If they don't burn down in time, I'll ping you to remove blockers 13:08:42 sounds like a plan 13:08:47 or just contact me when the page is all set :) 13:08:54 cool, will do 13:09:08 alright. Questions on your side ? 13:09:17 nope 13:09:21 alrighy then 13:09:24 +t 13:09:29 SergeyLukjanov: you around? 13:09:32 thank you for your time! 13:09:38 eglynn: have a good week 13:09:45 ttx, hello! 13:09:51 #topic Sahara 13:09:57 #link https://launchpad.net/sahara/+milestone/kilo-2 13:10:07 2 BPs left 13:10:10 we have two blueprints on the go 13:10:19 edp-spark-swift-integration waits for https://review.openstack.org/#/c/146659/ (-1’d for nit thing, will be updated and re-approved today) 13:10:26 and indirect-vm-access with https://review.openstack.org/#/c/133590/ in the gate 13:10:36 sounds good 13:11:00 so, should be delivered before tomorrow 13:11:12 heh, you pmake my job easy I see 13:11:26 hope so :) 13:11:33 note that we'll discuss reviews of Horizon panels at the cross-project meeting later 13:11:39 you might want to stay around 13:11:54 otherwise I'll bring the topic up anyway 13:12:10 yup, I remember 13:12:27 No other questions 13:12:32 I don't have a story for it, just want to discuss what's the best approach for doing it 13:12:46 it's a good discussion to have 13:12:51 it won't get any better i the future 13:12:59 I'm always on cross-project meetings, not aleays active due to the very late time :( 13:13:09 yep 13:13:10 nothing more from my side too 13:13:14 SergeyLukjanov: have a good day then! 13:13:21 ttx, thanks 13:13:25 ttx, you too 13:13:34 dhellmann: ready when you are 13:13:50 ttx: hi! 13:13:59 #topic Oslo 13:14:14 #link https://launchpad.net/oslo/+milestone/kilo-2 13:14:26 Looks all set for oslo-incubator tagging 13:14:38 yep, I think we're clear 13:14:42 dhellmann: anything we should wait on before we tag the incubator with the kilo-2 tag ? 13:14:54 usually we do it late, we can as well do it early 13:14:59 I think 13:14:59 * dhellmann checks the queue quickly 13:15:48 nothing in the queue looks like it's critical, so we could go ahead 13:16:00 ok, will do just after our discussion 13:16:02 Quick glance at https://launchpad.net/oslo/+milestone/next-kilo 13:16:18 any other library release this week? 13:16:33 no, we decided to hold off until next week because of the deadline 13:16:44 we'll have several on monday morning 13:16:48 yes, it's not a week where breakage is appreciated 13:16:59 utils, test, and db at least next week 13:17:20 yeah, I thought josh was going to wait to do the taskflow release, too -- bad communication there on my part 13:17:28 "I don't always break OpenSTack by releasing an Oslo library, but when I do, I do it after the milestone week" 13:17:37 no that's a t-shirt slogan 13:17:40 *now 13:18:18 OK, anything more before I start running script 13:18:20 ? 13:18:40 nothing to report, and nothing for the meeting agenda 13:18:58 alright then, tag on its way. 13:19:17 * dhellmann ducks 13:20:03 heh, you aren't the one running the experimental neutron-aaS-friends-supporting branch of release-tools now 13:21:04 ok done 13:21:29 dhellmann: It's so awesome to see so little work being done in the incubator those days :) 13:35:56 ttx: yeah, that'll change again next cycle when we shift back into "acquisition" mode, but I want us to set a goal of 1-2 cycles for incubation before graduation 14:54:44 ttx: I'm ready whenever you're ready. 14:57:44 mestery: ok, let's do this 14:57:48 #topic Neutron 14:58:05 #link https://launchpad.net/neutron/+milestone/kilo-2 14:58:18 7 Bps still up 14:58:27 and 18 bugs 14:58:34 ttx: Ack, all those BPs have a shot still. 14:58:37 They have patches in flight. 14:58:40 Should I treat any of those bugs as a milestone blocker ? 14:58:48 But I've told people that if they aren't in the merge queue by Wednesday morning they're out. 14:58:50 or just defer whatever doesn't make it ? 14:59:05 I don't think any are blockers at this point. 14:59:20 ok, so let's see if I can map those BPs to reviews 14:59:58 refactor-iptables-firewall-driver > https://review.openstack.org/#/c/152512/ says it partially implements -- so are more patches coming ? 15:00:15 * mestery looks 15:00:35 That's the last patch for that BP. 15:01:04 I'm confirming with ajo now, but that's what he told me Friday. 15:01:12 lbaas-api-and-objmodel-improvement > https://review.openstack.org/#/c/152171/ https://review.openstack.org/#/c/144834/ https://review.openstack.org/#/c/144832/ 15:01:29 Just got confirmation on https://review.openstack.org/#/c/152512/, it closed out refactor-iptables-firewall-driver 15:01:32 *closes 15:01:45 ttx: The LBaaS folks are having a sprint this week, I expect a lot of merges from them today/tomorrow. 15:01:59 dougwig has indicated that LBaaS V2 BP will be done before Kilo-2, barring merge issues 15:02:38 rootwrap-daemon-mode > https://review.openstack.org/#/c/84667/ https://review.openstack.org/#/c/82787/ https://review.openstack.org/#/c/145829/ 15:02:47 looks a bit far away 15:02:57 ttx: If otherwiseguy doesn't propose a new patch by this morning, I'll move it out. 15:03:25 extra-dhcp-opts-ipv4-ipv6 > https://review.openstack.org/#/c/136713/ 15:03:54 allow-mac-to-be-updated > https://review.openstack.org/#/c/112129/ 15:03:57 This one should merge today 15:04:10 yes those two are looking good 15:04:13 ++ 15:04:40 ofagent-flow-based-tunneling > https://review.openstack.org/#/c/130677/ https://review.openstack.org/#/c/130676/ 15:04:57 That one is a little further away than the prior too, but still close 15:05:03 rpc-docs-and-namespaces > https://review.openstack.org/#/c/149735/ 15:05:25 OK, if that is correct I can track completion and help updating BP status 15:05:30 I have an ask out to russellb on the status there, I suspect it may not be complete, but there's a lot of patches so it's hard to know :) 15:05:35 Thanks ttx! 15:06:05 sanity-checking the repos to see if tarballs are complete 15:06:16 cool 15:06:30 takes a bit of time 15:07:17 while I wait, other questions ? 15:07:27 I'm going to spend some time post our 1:1 going through the remaining bugs that are open yet 15:07:33 I'll have those cleaned up this morning with only ones realistically having a chance at Kilo-2 targeted 15:07:35 I'll ping you if it seems headed to the wall or if it looks ready 15:07:39 One more thing 15:07:45 #link https://docs.google.com/spreadsheets/d/1OQN0VlKzKC1gYlxgalQXKDTGGWogWFRtD3S5OpepsX4/edit?pli=1#gid=0 15:07:57 That's the tracking page for our plugin decomposition status 15:07:57 It's looking quite good actually! 15:08:01 You can ping me if it looks ready from where you're standing 15:08:03 We'll keep that updated as we go. 15:08:09 ttx: Ack 15:08:55 mestery: so those repos contains each vendor plugin 15:08:57 ? 15:09:04 Correct 15:09:13 The backend logic for the plugin, a thin shim is still in the neutron tree. 15:09:22 ok 15:09:50 The process has gone quite smooth actually, kudos to armax for leading this 15:09:59 ok, so we'll be in touch for the tag(s) 15:10:12 Thanks ttx! 15:10:19 I evolved the release scripts, they should support uploading neutron-*aas to same LP page now 15:10:26 fingers crossed 15:10:27 ++, awesome! 15:10:32 ;) 15:10:45 mestery: alright, have a nice day! 15:10:56 ttx: Thank you! You have a great evening! 15:11:37 nikhil_k: ready when you are 15:20:58 ttx: o/ 15:21:07 #topic Glance 15:21:14 #link https://launchpad.net/glance/+milestone/kilo-2 15:21:18 nikhil_k: o/ 15:21:30 I see 4 Bps still in progress 15:21:38 All likely to make it in the coming days ? 15:21:47 ttx: so, there was some confusion on some of them 15:21:55 a couple of them are ready 15:22:05 https://blueprints.launchpad.net/glance/+spec/replace-snet-config-with-endpoint-config and 15:22:08 https://blueprints.launchpad.net/glance/+spec/software-metadefs 15:22:18 * ttx looks at those 15:22:21 this is being tested and needs a small change 15:22:21 https://blueprints.launchpad.net/glance/+spec/taskflow-integration 15:22:33 this looks unlikely https://blueprints.launchpad.net/glance/+spec/swift-retry-wait 15:22:49 replace-snet-config-with-endpoint-config pending on https://review.openstack.org/#/c/150144/ IIUC 15:23:17 software-metadefs pending on https://review.openstack.org/#/c/148007/ 15:23:40 taskflow-integration... 15:23:40 ttx: yeah, I heard back just gunna review it 15:23:51 about replace-snet-config 15:23:52 is it just https://review.openstack.org/#/c/85211/ ? 15:23:57 yes 15:24:00 ok 15:24:06 swift-retry-wait... 15:24:19 ttx: the main blocker is https://bugs.launchpad.net/bugs/1412802 15:24:27 * nikhil_k waits 15:24:35 yeah, it looks way farther away, better concentrate on the other 3 15:24:55 how about we move this one to k3 already, to signal reviewers should focus on the other 3 ? 15:25:25 ttx: that sounds fine 15:25:31 ok, doing it now 15:25:50 About the bugs, anything we should block the milestone on ? 15:26:03 Or I should just defer whichever are not merged when the BPs are done ? 15:26:19 the main blocker is https://bugs.launchpad.net/bugs/1412802 15:26:33 right 15:26:42 we should keep this one as blocker 15:26:48 and may be we should let this one slide https://bugs.launchpad.net/glance/+bug/1221274 15:27:25 feels featury rather than buggy too 15:27:39 How about I mogve out of the milestone all but the critical one ? 15:27:50 If those get merged they will be reincluded anyway 15:27:50 yeah, feature related is https://review.openstack.org/#/c/145544/6 15:28:26 ttx: sure, if you have to. I was going to suggest to wait until tomorrow however, either way is fine 15:28:43 I think focusing on k3 and wrapping stuff up should like a better scenario 15:28:53 s/should/sounds/ 15:29:01 I prefer to use the k2 list as the blocker list at this point 15:29:16 ok, sure 15:29:45 OK, it's clean now 15:29:48 :) 15:30:02 Appreciate it. 15:30:03 I'll track those in the coming days and ping when if we won't hit the window or if all seem ready 15:30:13 ping me the other way around if you feel it's good to go too 15:30:20 Sure thing 15:30:20 Questions ? 15:30:27 Nothing for now :) 15:30:34 alright, you know where to find me 15:30:39 Have a good day 15:30:47 Have a good one, yourself! 15:31:30 thingee: ready when you are 15:31:38 ttx: hi! 15:31:45 #topic Cinder 15:31:50 #link https://launchpad.net/cinder/+milestone/kilo-2 15:31:59 I see 5 open BPs in my crystal ball 15:32:09 All still likely to make it ? 15:32:41 I moved out a lot of stuff that have little to no consensus. If anything is going to make it, it's these. 15:32:46 OK, let's map them to the corresponding reviews then 15:33:10 over-subscription-in-thin-provisioning seems to be waiting on https://review.openstack.org/#/c/142171/ 15:33:42 remotefs-share-cfg-improvements on https://review.openstack.org/#/c/149765/ 15:34:01 database-purge on https://review.openstack.org/#/c/146766/ 15:34:02 https://etherpad.openstack.org/p/cinder-k2-priorities 15:34:41 chiscsi-iscsi-helper > https://review.openstack.org/#/c/147758/ 15:34:50 adding them for the log 15:35:22 nfs-manage-unmanage > https://review.openstack.org/#/c/138125/ 15:35:36 All sounds doable 15:35:57 Theer are also 3 bugs. Are those blockers of just targets of opprtunity that I can defer to k3 if they miss ? 15:36:19 yes 15:36:28 (the latter) 15:36:41 yea latter 15:36:43 sorry 15:37:03 Alright, I'm all clear 15:37:07 last thing 15:37:09 http://lists.openstack.org/pipermail/openstack-dev/2015-January/055719.html 15:37:15 I'll track those 15:37:16 sorry for switching this on you 15:37:53 #info Cidner Blueprint/Spec approval deadline - February 15th 15:37:57 not sure if it's doable for something cross project next time on deadlines? Or a table somewhere? I can't imagine this is easy for contributors to keep track of 15:38:02 #info Cinder Code freeze for all features - March 10th 15:38:22 I posted most of them on https://wiki.openstack.org/wiki/Kilo_Release_Schedule 15:38:34 you're way ahead of me, thanks :) 15:38:48 but I need to adjust dates it seems 15:39:42 that's all for me 15:39:46 thingee: code freeze for all features -- what does that mean 15:39:54 features must be proposed ? 15:40:01 (as in, in code review ? 15:40:05