21:02:11 #startmeeting nova 21:02:12 Meeting started Thu May 9 21:02:11 2013 UTC. The chair is russellb. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:02:14 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:02:16 The meeting name has been set to 'nova' 21:02:16 who's around to talk nova? 21:02:21 o/ 21:02:23 <-- 21:02:23 hi 21:02:26 hi 21:02:26 hey 21:02:26 o/ 21:02:31 o/ 21:02:33 hi 21:02:39 #link https://wiki.openstack.org/wiki/Meetings/Nova 21:02:47 #topic release status - havana-1 21:02:55 #link https://blueprints.launchpad.net/nova/havana 21:03:02 #link https://launchpad.net/nova/+milestone/havana-1 21:03:24 havana-1 is scheduled for 3 weeks from today, which means patches need to be in in less time than that 21:03:28 probably may 21 21:03:39 so with that said, we need to be watching our goals for havana-1 21:03:43 \o 21:03:45 the blueprint list is looking pretty aggressive 21:04:12 take a look at the havana-1 list and let me know if the status needs updating on any 21:04:22 or if you feel like it should be pushed back, let me know that too 21:04:46 if you're the assignee, you *should* be able to update the status along the way yourself, so please do 21:05:39 any comments/questions on release / havana-1 status? 21:06:16 as we get closer, i will start hounding people for updates :-) 21:06:32 i'm not going to make https://bugs.launchpad.net/nova/+bug/1078080 happen soon 21:06:33 Launchpad bug 1078080 in nova "libvirt rescue doesn't respect image_meta passed in" [High,Triaged] 21:07:13 still want it on you? 21:07:22 or unassign? 21:07:31 actually, no. it doesn't really apply to ironic 21:07:42 k, removed you 21:07:45 id consider it a feature for baremetal at this point 21:07:46 so someone else can grab it 21:07:49 k 21:08:17 sounds like i can change it to wishlist then? 21:08:55 high is == "High if the bug prevents a key feature from working properly for some users (or with a workaround)" 21:09:06 "Wishlist if the bug is not really a bug, but rather a welcome change in behavior:] 21:09:12 from https://wiki.openstack.org/wiki/BugTriage 21:09:25 k, on to bugs 21:09:28 #topic bugs 21:09:33 we had a bug day! 21:09:37 mikal: how was it? 21:09:44 It seemed to go ok even! 21:09:51 Triage worked well 21:10:02 We didn't seem to _close_ many more bugs than normal though 21:10:10 triage uncovered a few important things though 21:10:12 But we found some imporant stuff in the triage process 21:10:13 that's quite valuable 21:10:21 Agreed 21:10:28 how many did we triage? 21:10:33 -ish 21:10:42 Last I looked (yesterday) about 60 bugs 21:10:51 cool, i like numbers 21:10:57 so shall we do it again? 21:11:05 Yes, for sure 21:11:09 Keep review lag in mind; we may have closed some bugs that just aren't all the way through the pipeline. 21:11:19 if we do it regularly, maybe there will be less in triage, and more time can be spent fixing 21:11:19 I think we said every two weeks? 21:11:26 mikal: sounds good to me 21:11:31 dripton: I was tracking "in progress", which happens when the review is sent 21:11:41 dripton: yeah, indeed. we can look at how many go to "in progress" though ... yes what mikal said :) 21:11:57 Its ok though 21:12:00 mikal: you're anticipating my suggestions before I can make them 21:12:02 Perhaps its because triage was such a mess 21:12:04 Baby steps 21:12:11 from mikal's email I thought most of the focus was intended to be on triage so I think I misunderstood 21:12:16 yeah that took all of my bug time 21:12:25 triage is step 1 really 21:12:31 melwitt: I think triage was important, so I'm not sad if people focussed on that 21:12:55 Where did we end up doing all the triage and discussion? Was it openstack-nova? Did I miss it because I was busy? 21:13:01 * comstud lurks 21:13:07 could non-core deveveloper do triage? 21:13:17 cburgess: there was an irc chanell (openstack-bugday) but it was basically idle when I was awake 21:13:35 * russellb talked in #openstack-nova the whole time ... 21:13:37 i think we should just use -nova 21:13:38 senhuang: could do some confirming of bugs or asking for more info etc... 21:13:43 senhuang: to my understanding yes, someone was during the day (he could mark things incomplete at least) 21:13:48 Opps.. ok my bad. I'll be sure to join it next time. russellb did give me a bug yesterday that I got a review up for today but I had wanted to help more. 21:13:51 anyone is welcome to do triage 21:13:59 cyeoh: mikal: thanks! 21:14:04 triage instructions here: https://wiki.openstack.org/wiki/BugTriage 21:14:06 #link https://wiki.openstack.org/wiki/BugTriage 21:14:17 We also ended up with a wiki page with suggestions on how to write a good bug report, so that's cool 21:14:26 nice 21:14:28 senhuang: I think you need to join https://launchpad.net/~nova-bugs to triage, but it's open to non-core 21:14:39 alaski: good point 21:14:44 forgot about that 21:15:07 alaski: that is cool. will do 21:15:14 mikal: thanks for organizing / posting stats 21:15:18 We should add that to the triage instructions 21:15:20 yeah, I'm not core but I was able to confirm a few/add comments, resolve inconsistent state 21:15:21 russellb: NP 21:15:36 any more comments/questions on bugs? 21:16:05 cburgess: i saw your patch go up today btw, haven't had a chance to look, but thanks a lot! will look as soon as i can 21:16:13 No worries 21:16:19 have a link for the log? 21:16:58 Sorry what? 21:17:04 link to the review 21:17:08 https://review.openstack.org/#/c/28717/ 21:17:17 #link https://review.openstack.org/#/c/28717/ 21:17:18 thanks 21:17:24 alrighty, onwards 21:17:31 #topic sub-team reports 21:17:33 russellb: have you had a chance to the proposed fix for bug https://bugs.launchpad.net/nova/+bug/1049249 21:17:35 Launchpad bug 1049249 in nova "Remove plugging of internal classes from configuration" [High,Confirmed] 21:17:47 #link https://wiki.openstack.org/wiki/Teams#Nova_subteams 21:17:55 sub-teams are listed there 21:18:08 i'd like to start getting quick reports from these teams when there's useful info to report 21:18:27 so any representatives want to recap what you're up to? 21:18:39 suree 21:19:09 so there was talk about where to have the placement of said 'taskflow' library to start 21:19:27 *a place where it can be rapidly worked on 21:19:41 and where it solves an immediate need 21:20:08 in XenAPI, we went over lots of blueprints, and some hotish bugs, making progress 21:20:20 #help https://blueprints.launchpad.net/nova/+spec/xenapi-vif-hotplug needs some help 21:20:37 what kind of help 21:20:40 someone to do it? 21:20:46 yup, ideally 21:20:46 so there was some consensus that cinder might be a good place for that, but also consensus that it would be very useful to have core memebers of different openstack subprojects involved in reviewing said code, the design process and so on, so that said library does not just become only useful for nova 21:21:10 harlowja: thinking of trying something on stackforge? 21:21:24 there was some talk about stackforge 21:21:34 On more XenAPI thing, poeple are working on SmokeStack and getting that working, that is all from me. Sorry to inteject. 21:21:42 johnthetubaguy: +1 :-) 21:21:42 harlowja: you mean, "only useful for Cinder" 21:21:46 *yes thx 21:22:08 stackforge could work, I guess its that copy you are trying to avoid? oslo incubator? 21:22:29 well not just the copy, the red tape is part of it 21:22:51 could start in stackforge, maybe eventually it goes to oslo later once it materializes 21:23:06 makes sense 21:23:08 cool, well thanks for the updates 21:23:11 … just want to announce a VMwareAPI subteam meeting next week … #link 21:23:12 For the scheduler we're basically doing a first pass throught 21:23:12 the ~11 subjects brought up at the conference, there'll be more 21:23:12 detail coming soon. 21:23:12 One interesting issue is `future of scheduler' which is 21:23:13 really an idea to have the scheduler find the nodes but 21:23:15 #link https://wiki.openstack.org/wiki/Meetings/VMwareAPI 21:23:15 not actually start the instances, have an orchestrator do 21:23:17 that. 21:23:42 russellb so there might be some ongoing discussion about placement, but there was mostly agreement that it might fit best in cinder for now, its a tricky one though 21:24:07 i am fine with it on stackforge, with core people from the different teams providing input 21:24:08 harlowja: is this placement about selecting a node for volume? 21:24:22 harlowja: what's the problem with stackforge? 21:24:31 unsure, jgriffith has an AI to help flush that out 21:24:31 n0ano: re: future of the scheduler, https://blueprints.launchpad.net/nova/+spec/query-scheduler ? 21:24:54 devananda so there was disussion about how starting on stackforge may create a project that is useful for all, but useful for none :-p 21:25:01 russellb: yeah, that was it 21:25:10 cool 21:25:15 russellb, yeah, that's it 21:25:30 alright, couple of quick announcements, then open discussion (and can talk more about these teams activities if needed) 21:25:36 #topic other announcements 21:25:45 ah. 21:25:55 I should have waited for here to announce sorry. 21:25:57 I updated a wiki page to describe support states of virt drivers 21:26:08 #link https://wiki.openstack.org/wiki/HypervisorSupportMatrix 21:26:31 johnthetubaguy says they're working to move XenAPI up quickly back to group B, and eventually group A 21:26:36 i know there's work on baremetal testing, too 21:26:45 would like to see all drivers move out of group C eventually 21:27:16 other note ... i started a "virt driver architecture" thread today, check it out 21:27:24 i don't want to go into it too much here and fragment the conversation 21:27:24 :-) trying 21:27:41 #topic open discussion 21:27:52 may I ask about a direction for one particular patch? 21:27:53 hartsocks: sorry, didn't mean to cut you off if you had more to say about your team meeting 21:28:13 rerngvit: yes 21:28:32 russelb: y'all type fast. 21:28:35 so would any nova core members like to join in help said taskflow library be the best it can be, i know some about nova, but not as much as everyone else, and i'd like the library to be able to plug-in to the future of nova 21:28:36 this patch(https://review.openstack.org/#/c/18462/ ) is postponed from Grizzly because we don't know how this should be implemented 21:28:53 hartsocks: irc meetings can get crazy, heh 21:29:03 is it still the case? that I should wait of decision or I can progress on with it? 21:29:29 harlowja: I am not core, but interested in taskflow from the live-migration refactor blueprint sense 21:29:43 rerngvit: that was blocked because of the grizzly feature freeze, so it's fine now 21:29:50 harlowja: i'll probably lurk on the taskflow stuff, not sure how actively i'll contribute though 21:29:53 johnthetubaguy agreed, i can help u sync up if u want about what is happning 21:29:54 rerngvit: there were a few people working on that ... need to check for duplication 21:30:18 harlowja: I also want to lurk, but can't commit to much help atm 21:30:19 harlowja: +1 its just the meeting time sucks in my timezone 21:30:26 johnthetubaguy ya 21:30:27 ok, thank you. 21:30:42 rerngvit: actually looks like the blueprint in the havana plan is assigned to you, i think we're good. 21:30:45 https://blueprints.launchpad.net/nova/+spec/utilization-based-scheduling 21:30:53 rerngvit: so yes, please re-propose when you're ready :-) 21:30:58 alaski devananda great to have u guys 21:31:02 re: blueprints - i am starting to look at https://blueprints.launchpad.net/nova/+spec/glusterfs-native-support 21:31:03 also, any -core folks interested in join in on Ironic? 21:31:10 ok thanks 21:31:22 i emailed the original author, he said he didn't have time to work on it 21:31:31 devananda i'm not core but i'd like to help make sure u get whatever u need from y! people 21:31:36 devananda: certainly an interested observer ... my hands are a bit full atm though 21:32:26 devananda: where will you discuss things? openstack-dev with [Ironic], #openstack-ironic? code on stackforge? 21:32:32 russellb: ofc :) 21:33:04 russellb: yes. openstack-dev [ironic], also there is an #openstack-ironic channel, and the code will be on gerrit (not stackforge) once the name passes trademark checks 21:33:28 I can't believe I forgot to mention Ironic in this meeting! 21:33:34 :) 21:33:55 so yeah, if you didn't follow ... the Technical Committee approved Ironic as a new incubated project for the split out of baremetal from Nova 21:33:59 I think it's really exciting stuff 21:34:04 congrats to devananda and crew 21:34:17 \o/ 21:34:30 devananda +1 21:34:41 first meeting will be monday 1900 utc 21:34:59 woot. 21:35:01 if all goes well, we will be marking the current baremetal driver as deprecated in havana, and remove it in I 21:35:28 we'll see how it goes, but I have a ton of faith in the guys that have been driving it :-) 21:35:37 russellb: going back to the group c comment on the hypervisor support matrix, just curious what the red indicates in the x'ed cell for powervm here? https://wiki.openstack.org/wiki/HypervisorSupportMatrix#Hypervisor_feature_support_matrix 21:35:47 mriedem1: ask sdague, he did that 21:36:03 hah 21:36:06 heh 21:36:08 mriedem1: just color testing 21:36:11 mriedem1: fear not :) 21:36:18 sorry, I was chatting with dan earlier about making the x's pop more 21:36:22 my fault 21:36:26 so figured out how to make them red 21:36:27 busted 21:36:32 yes, busted indeed 21:36:42 pay no attention to the man behind the curtain.... 21:37:25 I know I am coming really late to the meeting, but since its in open discussion I thought I would plug the work Bluehost has done to nova. I haven't had time to dig in but it looks interesting as there cloud is 16k nodes. Slides http://www.slideshare.net/junparkearth/blue-host-openstacksummit2013 code https://github.com/UpooPoo/nova 21:37:43 sdague: no problem - was just wondering if i needed to take something back to my team 21:37:44 thanks 21:37:45 re: ironic, i could use a few ppl with deeper openstack knowledge to at least review, if not contribute, to the framework, once there is some code on gerrit 21:37:50 UpooPoo? 21:37:53 lol 21:37:56 wanted to mention https://blueprints.launchpad.net/nova/+spec/nova-network-legacy going to start up patchsets for modifiy libvirt and baremetal(ironic, now?) that i had abandoned previously 21:37:56 which i'm thinking should be any day now 21:37:59 yeahhhh 21:38:08 asadoughi: great 21:38:24 devananda: I'm happy to review, but I'm maxed out on other stuff coding wize 21:38:35 to help align it with other openstack services and APIs and stuff 21:38:50 mikal: that'd be awesome 21:38:59 russellb: with 16k node cluster they can call it whatever they want 21:39:07 jog0: lol, fair enough 21:39:25 harlowja: was there anything you wanted to bring up in the meeting for default AZ? re: https://review.openstack.org/#/c/28645/ - i thought you mentioned that in #openstack-nova earlier today 21:39:29 but yes, really want to talk to them more ... 21:39:32 they have a quantum patch set too https://github.com/JunPark/quantum/tree/bluehost/master 21:39:33 devananda: the project is called openstack/ironic, right? 21:39:41 mikal: yes 21:39:49 mikal: it's in LP. just not in gerrit yet 21:39:50 ironic may get the award for most clever codename yet 21:39:58 mriedem1, oh yes thanks! 21:40:01 (hopefully it passes) 21:40:12 russellb: let's just hope it passes lawyer checks! 21:40:41 so there was https://review.openstack.org/#/c/28645/ but i am slightly confused as to which AZ we should actually select for an instance 21:41:05 the instance db entry has a AZ field, but then the current code uses the host which the compute node is on, and then there is aggregates, and ... 21:41:15 I am hacking on it here https://github.com/devananda/ironic until it has a Real Home (tm) 21:41:40 #note ironic is here until it has a real home: https://github.com/devananda/ironic 21:42:04 devananda: would you prefer nova baremetal patches in the interim or wait for ironic to happen? 21:42:17 any thoughts on which az we should really be using would be appreciated 21:42:26 asadoughi: if they are fixing bugs in baremetal, yes please! 21:42:40 which reminds me, lifeless has been a bug-reporting machine the last few days 21:42:44 any particular reason why AZ should be a field of an instance? 21:43:35 devananda: comes from trying to use it :) 21:43:42 * lifeless doesn't mean that nastily 21:43:52 maybe just remove it from instance altogether, and use the one from host/whatever 21:44:38 is there a reason/usage of it existing in the instance table though that i might not be aware of 21:44:58 it sort of comes down to what is the defintion we are picking for an AZ 21:45:12 if an AZ is an aggregate, the hosts can be in multiple aggregates 21:45:44 aggregates aren't user facing IIRC 21:45:56 AZ is supposed to be the user facing choice 21:46:02 correct 21:46:35 so then whats in the instance table would be the one true AZ, and not the AZ of the host it sits on 21:46:43 still, it can be kept as a property of the host.. can different instances on the same host belong to different AZs? I hope not.. 21:46:58 let's see if we can sort it out in gerrit, i need to refresh myself on the code some more to comment 21:47:03 glikson: yeah that would kind of defeat the point of AZs 21:47:28 if two instances with different AZs existed on the same host 21:47:45 devananda: well in the case of the baremetal patch i am thinking of .. it was a bug that turned into a blueprint and is targeted for havana-2. any differing thoughts? 21:48:01 asadoughi: link? 21:48:15 devananda: https://blueprints.launchpad.net/nova/+spec/nova-network-legacy 21:48:35 russellb so any comments on https://review.openstack.org/#/c/28645/ would be appreciated, was trying to fix phils bug there, but it seems like there is more needed input than what i have 21:48:47 #link https://bugs.launchpad.net/nova/+bug/1172246 21:48:48 Launchpad bug 1172246 in nova "AZ reported wrongly until instance is scheduled" [Medium,In progress] 21:49:07 asadoughi: that's a fix in my book :) 21:49:33 cool thanks 21:50:24 alright, if anyone wants to chat further, #openstack-nova is always open 21:50:26 thanks for coming! 21:50:30 #endmeeting