14:00:39 #startmeeting Nova 14:00:39 Meeting started Thu Sep 4 14:00:39 2014 UTC and is due to finish in 60 minutes. The chair is johnthetubaguy. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:40 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:43 The meeting name has been set to 'nova' 14:01:18 ohai 14:01:25 o/ 14:01:29 o/ 14:01:30 \o 14:01:35 hi 14:01:37 bauzas: I owe you a follow-up 14:01:40 #topic Juno status and Feature Freeze 14:01:43 hi all 14:01:47 so feature freeze 14:01:48 o/ 14:01:57 we have stuff waiting in the gate still 14:02:01 ttx is helping track that 14:02:02 adrian_otto: nope, I owe *you* :) 14:02:16 #link https://etherpad.openstack.org/p/SC1ILk7zMT 14:02:39 wow thats is a a big list 14:02:43 its been as brutal as ever really, although this time we had lots approved yesterday but not through the gate 14:02:56 jogo: the list at the bottom is what we are watching now 14:03:08 \o 14:03:13 jogo: the other stuff were mostly things in the gate before ttx and I trimmed the list this morning 14:03:16 but yeah, ouch 14:03:30 johnthetubaguy: am I missing where SRIOV is there? 14:03:45 dansmith: I pushed that into RC-1 already 14:03:54 o/ 14:04:03 oh, I thought it'd still be here, okay 14:04:32 yeah, it didn't have anything in the gate when I last look 14:04:39 at least not linked to the blueprint whiteboard 14:04:42 but anyways 14:04:45 #link https://launchpad.net/nova/+milestone/juno-3 14:04:56 #link https://launchpad.net/nova/+milestone/juno-rc1 14:05:39 #link https://blueprints.launchpad.net/nova/juno 14:06:09 most of the pushed out stuff, is needscodereview in here: 14:06:13 #link https://blueprints.launchpad.net/nova/trunk 14:06:34 so… we actually got quite a few more blueprints into juno-3 that it was first looking like 14:06:41 but yeah, lots didn't make it 14:06:53 so feature freeze exceptions 14:06:58 :) 14:07:11 is everyone happy with the process, like three cores to get you in? 14:07:35 lol the holidays can make that tuff 14:07:44 ndipanov isn't happy with 3 cores :) 14:07:57 I think the 3 cores sounds sane 14:07:59 i think the question came up why 3 14:08:01 I think the point of the three core rule was to raise the bar, and it has done that 14:08:08 so I'm happy with it 14:08:09 i remember us talking about it in a meeting, 14:08:09 yeah, there were some concerns about why 3 14:08:13 yeah 14:08:25 2 wasn't cutting it in icehouse 14:08:31 right 14:08:39 so, we have a load of stuff that got approved, but still didn't make it, seems like they should go first 14:09:01 mriedem: dansmith: for the record, yeah, 2 didn't work well, lets try 3 cores this time 14:09:16 we ironic has three 14:09:22 also, what's the FFE land cutoff time? 14:09:26 johnthetubaguy: so, it seems to me that as soon as ironic is ready, we need to let that kinda take priority 14:09:29 right so specifics 14:09:33 i recall someone pointing out that simply throwing more people at the task is not likely to fix it:) 14:10:09 sdague: let me find a link to mikal's email 14:10:15 Ironic is requesting an ffe 14:10:27 basically we figured a fix date after the fiasco with spec feeze 14:10:32 a week on friday I think 14:10:37 does that sound OK? 14:10:41 yeah 14:10:46 johnthetubaguy: yeh, sounds fair 14:10:57 dansmith: johnthetubaguy we need to kill that first patch in ironic in order to let the others land 14:11:02 sdague: much more and we risk rc1 was the thinking 14:11:26 danpb: I think the idea was we want it all, or non of it? 14:11:32 danpb: afaik, that first patch is there so we can +A everything else, and then land in one swoop 14:11:37 #link http://lists.openstack.org/pipermail/openstack-dev/2014-September/044660.html 14:11:43 I think we just +A the bottom patch when we're ready, I'm not sure we need to remove it 14:11:47 but it doesn't really matter 14:11:48 mikal's timeline 14:12:03 #link http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg33817.html 14:12:14 imho its kind of crazy to push such patches at all 14:12:17 oops, thanks 14:12:34 danpb: what such patches? 14:12:37 danpb: this is what we decided at the summit, makes it easy to go all or nothing 14:12:37 yeh, wouldn't it better to -2 the actual functional patch? 14:12:40 blocking ones? 14:12:45 s/summit/midcycle/ maybe? 14:12:51 the bogo-patch seems odd 14:13:03 sdague: it came from people complaining that -2 is "mean" 14:13:04 ah, OK 14:13:16 sdague: and potentially would keep people from seeing real patches on their radar 14:13:17 dansmith: ... um, even with reasons? 14:13:41 ah, OK… well anyway, we have what we have, and we seem to kinda agree with that it is doing at least 14:13:43 dansmith: ok, well, if we think those are ready, can we just rebase out the bogo patchnow? 14:13:46 sdague: yeah, don't ask me, I don't get that part, but the "I filter out anything with a -2 on it" makes sense of course 14:13:58 sdague: yeah, that's what i would have expected 14:14:00 sdague: surely, I'm just saying I don't really care enough to do it 14:14:12 but ho hum, i guess it isn't critical 14:14:15 it really doesn't matter either way 14:14:17 I can do it, if we just need a volunteer 14:14:17 right, lets move on 14:14:24 as long as we push ironic forward 14:14:25 although we would need to add __init__.py to a different patch 14:14:37 since that's what the first patch does 14:14:41 so, ironic and SRIOV do we have cores in place for those now? 14:15:06 yes: Ironic Driver (7 patch series starting at 111223) (sponsoring cores: dansmith, jogo and danpb) 14:15:14 yes! sponsoring cores: dansmith, jogo and danpb 14:15:20 johnthetubaguy: I don't think we've collected cores for SRIOV yet because it seemed already granted, hence the question about the email this morning 14:15:22 what about for the sriov one? 14:15:23 right 14:15:41 johnthetubaguy: obviously I am on board for it, but not sure we've even looked for the other two yet 14:16:09 johnthetubaguy: I would assume russellb would as well, since he was working hard on it for a while there, but I think he's tied up today 14:16:35 in another meeting, *checks scrollback* 14:16:35 dansmith, I'd be up for it 14:16:44 dansmith, just didn't see the email 14:16:46 russellb: sponsor SRIOV? 14:16:46 #info ironic gets FFE dansmith jogo danpb 14:16:47 #info SRIOV had official back door with support in last nova-meeting, but collecting sponsors on ML 14:16:47 OK 14:16:51 ACK on sponsoring SR-IOV 14:16:52 russellb: basically will you sponsor the SRIOV one 14:17:16 arrgh, netsplit in the middle of a meeting 14:17:16 oh boy, net split 14:17:40 :-p 14:17:43 this one was not huge 14:17:44 fortunately we seem to have kept the important people :-) 14:17:45 anyways, sounds like we are closeish on most of those 14:17:50 Thankk you 14:18:16 review timeline, by friday? 14:18:23 next friday 14:18:29 that's what i meant yeah 14:18:30 ok 14:18:32 yep 14:18:37 that's merged by next friday 14:18:45 not merely queued with +a, right ? 14:18:58 yeah, next friday 14:18:58 cool, so any more exceptions people wanted to cover here? 14:18:58 any other process questions? 14:19:04 probably, but using judgement with the gate's status might be reasonable 14:19:05 dansmith, still can't see the email but I am on boeard if oyu need me 14:19:13 ndipanov_: no email yet 14:19:13 danpb: yeah, ideally merged, certainly approved 14:19:21 johnthetubaguy: i missed the start, have you gone over the other FFEs requested on list yet ? 14:19:23 johnthetubaguy, the numa one? 14:19:34 NUMA,serial console at least have 3 sponsors i believe 14:19:42 danpb: nope, not gone through those, we can do that on the ML for most of them 14:19:48 ah ok 14:20:16 so, just to be clear, no approvals till we get juno-3 tagged, regardless of FFE status right? 14:20:33 #info please lets cut juno-3 tag before we approve anything else 14:20:49 johnthetubaguy: if so, you should send a direct email to nova-core I think 14:20:55 johnthetubaguy: lots of core folks that don't attend this meeting 14:20:56 johnthetubaguy, ack 14:21:13 dansmith: ttx did send that mail, but it used the [all] tag 14:21:22 yes good point I would have missed this easily (but would have asked) 14:21:22 johnthetubaguy: right, I'm saying direct to nova core 14:21:57 dansmith: yeah, I would, but I don't have the list handy, or time today, anyone fancy doing that? 14:22:14 sure, and say what? don't approve until j-3 is tagged? 14:22:15 i can do that 14:22:16 johnthetubaguy: per my understanding, ttx's email was not that restictive 14:22:19 I don't have the list either, but I'll try to dig it up and do i... 14:22:24 er, yeah, mriedem should do that :P 14:22:30 #help ideally someone relay direct email to nova-core about nova approves 14:22:30 i'll be the intern 14:22:31 lol 14:22:51 mriedem: sweet, thanks, I could do with a coffee, if you can get travel approval 14:22:57 nice 14:23:03 anyways 14:23:09 the email is just saying don't approve anything right? 14:23:10 mriedem, while you're in the UK... 14:23:15 mriedem: yeah 14:23:18 mriedem: +1 14:23:20 that includes bugs etc? 14:23:24 yep 14:23:26 ok 14:23:29 on it boss! 14:23:37 unless they are critical blockers, but yeah 14:23:43 * johnthetubaguy giggles 14:23:50 OK... 14:23:57 any more we need to cover here 14:24:01 I vote the rest we do on the ML 14:24:15 please do shout if you don't think something should get an exception 14:24:43 but we kinda need to keep the number fairly small, if NUMA gets in, not much else can merge, in reality 14:25:00 and I think NUMA probably should be allowed in, given it got approved already 14:25:08 we've got a few things which are 1/2 merged 14:25:13 will read through stuff on ML 14:25:18 johnthetubaguy, from the number of patches perspective? 14:25:21 danpb: yeah, I think they should come first 14:25:24 ndipanov_: yes 14:25:26 i think it is important to get them fully merged 14:25:31 as releasing 1/2 a feature is madness 14:25:46 johnthetubaguy, yeah... sigh damned if you do damned if you don't (split it up) 14:26:03 danpb: agreed, most that were partial, apart from NUMA were not complete anyways, and slightly on going stuff, so its not that bad 14:26:23 johnthetubaguy, the serial console one is also half 14:26:30 the serial console one is the signficant one i'm thinking of here 14:26:39 right, these ones: https://etherpad.openstack.org/p/SC1ILk7zMT 14:26:46 ah yes, that's the list 14:26:54 anyways 14:26:59 I would like to remind people that as we rush to land new things we destablize the code and introduce new bugs: so we need to be careful and watch for new bugs 14:27:00 I think we get what is going on 14:27:07 http://status.openstack.org/elastic-recheck/data/uncategorized.html 14:27:11 jogo: agreed 14:27:11 http://jogo.github.io/gate/ 14:27:15 a good segway 14:27:17 #topic Bugs 14:27:21 things are already destabilizing a little 14:27:29 its meant to be stabilisation time 14:27:46 any well, the gate says we are doing a bad job of that right now 14:27:48 johnthetubaguy: I would say that is ironic, but that is now trademarked 14:27:58 lol 14:28:02 hehe 14:28:04 so, how many weeks of bug fixing do we have in the schedule now 14:28:06 lol 14:28:15 #link http://54.201.139.117/nova-bugs.html 14:28:18 let me check... 14:28:22 danpb: 6 14:28:32 #link https://wiki.openstack.org/wiki/Juno_Release_Schedule 14:28:38 jogo, can't see the ling on github tho 14:28:49 so we just RC1 around September 25th 14:29:04 then its bit hitters only backported onto a branch after that 14:29:05 ndipanov_: it takes a second to load from graphite.o.o 14:29:19 so, more like three weeks 14:29:23 but yeah 14:29:43 johnthetubaguy: "big hitters" ? 14:29:54 johnthetubaguy: I am hoping we can release juno with <1000 open bugs 14:30:03 johnthetubaguy: was trying to look up the weird british slang, but figured maybe it was a typo 14:30:10 we have 1026 today 14:30:21 dansmith: critical and high bugs, tagged with rc1 stuff 14:30:32 johnthetubaguy: yeah, you said "bit hitters" :) 14:30:37 dansmith: you know, I think thats a cricket thing, oops, I moan about baseball stuff 14:30:42 jogo: I spent yesterday in the bug tracker. There are really a ton of valid things that would be nice to have > 3 weeks on, sadly 14:30:43 hah 14:30:47 dansmith: you were right heh 14:30:50 johnthetubaguy: I targetted one bug to the rc 14:30:56 there is a py26 regression 14:30:56 i thought big hitters was a baseball thing :-) 14:31:06 we don't have slang - we have English 14:31:08 danpb: oh maybe, lol 14:31:18 anyways 14:31:20 sdague: yeah I noticed, you did make a huge dent 14:31:37 jogo: tjones was working it as well, not all me 14:31:52 sdague: I mean the way specs are for kilo, we might have kilo-1 for bugs, which is maybe not totally aweful 14:32:02 I wonder how many bugs need to go through secondary triage (after they get tags) 14:32:03 but lets not re-open that wound just now 14:32:35 johnthetubaguy: yeh, fair, mostly wanted to heads up the one regression bug - https://bugs.launchpad.net/nova/+bug/1306559 14:32:37 Launchpad bug 1306559 in nova "Fix python26 compatibility for RFCSysLogHandler" [High,Confirmed] 14:32:37 OK, so we should probably make sure we know what critical bugs there are 14:32:43 eek, thanks 14:32:44 as that seems like we should definitely address 14:32:57 johnthetubaguy, sdague asI mentioned the other day - bugs we really want to fix probably need bps anyway 14:32:58 it's mostly an oslo sync I think 14:33:28 ndipanov_: blueprints for fixing bugs? 14:33:51 ndipanov_: we should track it, but that feels a bit bad 14:33:55 uh, oh 14:33:57 dansmith, for refactoring 14:34:20 anyways... 14:34:23 #topic gate status 14:34:24 ndipanov_: okay, "blueprints for refactoring" != "blueprints for bugs" to me :) 14:34:28 so things are not happy 14:34:50 any urgent stuff we need people to look at? 14:35:00 sdague: that py26 logging fix is already in nova 14:35:10 mriedem: ok, can you close it then? 14:35:13 sdague: yup 14:35:20 awesme 14:35:28 sdague, Just wondering, Re: bugs "There are really a ton of valid things that would be nice to have > 3 weeks on, sadly" - Do you have an etherpad list of those bugs list somewhere that can be looked at, for for further triage/root-cause analysis? 14:35:30 that's one of the issues with the tracker state right now... a ton of already fixed things in it 14:36:00 OK, so gate state 14:36:01 sdague: you mean bugs which have merged into git, but not been closed in launchpad ? 14:36:02 kashyap: not really, I was just trying to get a mental sense of things by hacking at the > 1000 bug list 14:36:07 anyone got anything about that? 14:36:17 johnthetubaguy: top 3 are infra issues 14:36:26 and then the ssh one that we know and love 14:36:32 danpb: yep. 14:36:35 ah, yes 14:36:47 cool, so I am sure there are others 14:36:50 but lets move on 14:37:00 #topic Open Discussion 14:37:01 sdague: ha, i can't close that bug out b/c launchpad times out b/c there are too many projects tied to the bug :( 14:37:02 so we could take the more brutal big lock approach on the ssh one 14:37:02 sdague, Okay, thought so :-). Staring at LP bugs, it's kind of hard to classify what are reasonable for a specific release as there's not much tags/categorization per release based. 14:37:30 Hi Ironic has a question on how to go about landing the baremetal-api proxy stuff 14:37:45 see https://review.openstack.org/#/c/116316 as ref: 14:37:56 (note that patch is very ruff) 14:37:57 mriedem: try deleting projects 14:38:06 sdague: yeah did that 14:38:41 NobodyCam: whats the worry? 14:38:55 how to land it while nova bm is in place 14:39:10 there will be one cycle where we overlap 14:39:24 NobodyCam: can't you detect ironic vs baremetal node, and just do the right thing, or do both? 14:39:34 NobodyCam: can the proxy and the nova-bm extension be exclusive, so you can only have one enabled at a time? 14:39:41 NobodyCam: I guess its not quite like nova-network/neutron switch over 14:39:42 or that. 14:39:45 johnthetubaguy: of one cycle there will be both 14:39:56 s/of/for/ 14:40:04 NobodyCam: but not at the same time 14:40:12 NobodyCam: yeah, but most people will only run one or the other, I guess it depends on the migration strategy... 14:40:14 NobodyCam: he means detect which is in use 14:40:36 I was thinking a conf var as a switch 14:40:55 you already have a conf var, right? 14:40:58 the virt driver? 14:41:02 NobodyCam: I guess we can depreate that conf with baremetal 14:41:16 dansmith: we don't usually read that in the API though 14:41:23 but yeah, that might do the trick 14:41:34 johnthetubaguy: I know, but we read the network one for switching nova/neutron, 14:41:34 we can try that 14:41:37 even though that's disgusting 14:41:43 johnthetubaguy: I wonder if there's deployers that don't set that conf in the api 14:41:50 I'm sure there are, 14:41:55 but we could put that into the release notes 14:41:59 dansmith: its less bad than another conf I guess 14:42:00 right 14:42:03 instead of introducing a new conf just to get rid of it 14:42:05 yeah, needs documenting 14:42:17 I guess either way, the config is changing, so yeah 14:42:31 yeh, adding to release notes is fine, it should land as deprecated and be removed in K 14:42:33 NobodyCam: does that answer your question now? 14:42:58 I think so. we'll give it shot and see what we come up with...TY :) 14:42:59 the process should be deprecated... that is. So people know it's just needed during Juno 14:43:04 sdague: no, we're saying use the existing virt driver option 14:43:31 ah yeah 14:43:31 jroll: right, we should just be clear that we only expect people to have it in their api config for juno because of transition 14:43:33 although we remove needing the option when baremetal goes 14:43:40 sdague: +1 14:43:42 sdague: right, "the process" 14:43:42 cools 14:43:51 :) 14:43:53 yep 14:44:09 thank you all :) 14:44:27 #info baremetal proxy api could use the virt driver setting to decide what mode its in, until we rip out baremetal 14:44:43 cool, any more topics for today? 14:45:07 not from Ironic 14:45:09 :) 14:45:14 johnthetubaguy, so when is j-3 tagged? 14:45:16 lots of meaty things on the ML, but thy are probably mostly better discussed there, once people have the context, but we could touch on them, if wanted 14:45:19 i guessing we don't have migration support for bare metal -> ironic for juno at this point, so we won't be able to finally kill it until Lxxxx at least now ? 14:45:19 or expected to be 14:45:41 I thought the migration parts where there 14:45:50 danpb: we have migration support 14:46:03 * jroll digs for links 14:46:03 yeah 14:46:16 oh do we, was that a different set of patches from the main ironic addition series 14:46:21 nidpanov: juno-3 is tagged once the remaining patches (5) get through the gate, or we get bored and tag it anyway, ttx is tracking that 14:46:24 or am i just being blind 14:46:26 danpb: https://review.openstack.org/#/c/112402/ 14:46:30 it's in ironic tree 14:46:46 jroll: ah, ok, thanks 14:46:48 danpb: we're also working on grenade stuff 14:46:57 johnthetubaguy, so the alredy approved pathces that got a -2 from you can be just re-approved (well after rebase...)? 14:47:08 yeh, it's mostly landed, there are a few last patches, but I consider that on target 14:47:24 so, can we update the deprecation message in baremetal driver.py 14:47:32 so say that we'll kill it in Kilo ? 14:47:44 currently it gives no target for death 14:47:51 "kill it in kilo" sounds like a Janet Evanovich novel 14:47:57 nidpanov: ideally not yet, just to late the gate drain and be sure its tagged, but I could be missing something 14:48:11 johnthetubaguy, no I mean when it's tagged 14:48:20 not gonna do anything before that 14:48:32 s/when/once/ 14:48:44 nidpanov: in your cases, yes, where the blueprint is not marked as complete yet 14:48:47 yeh, it's probably just something to make sure happens by rc1 14:49:12 danpb: worth a critical bug so we don't forget that I guess? 14:49:16 let's actually have the ironic driver merged first 14:49:32 or add it to the end of that patch series 14:49:35 sdague: pessimist :-P 14:49:49 yeah, cart and horse, or something 14:50:06 OK, are we done, seems like conversation is drying up now :) 14:51:04 cool, thanks all 14:51:14 happy bug fixing and reviewing 14:51:19 #endmeeting