14:01:11 <mriedem> #startmeeting nova 14:01:12 <openstack> Meeting started Thu Apr 7 14:01:11 2016 UTC and is due to finish in 60 minutes. The chair is mriedem. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:01:13 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:01:17 <openstack> The meeting name has been set to 'nova' 14:01:18 <ndipanov> yo 14:01:18 <markus_z> o/ 14:01:20 <sarafraj> o/ 14:01:21 <edleafe> \o 14:01:22 <alaski> o/ 14:01:22 <diana_clarke> o/ 14:01:22 <takashin> o/ 14:01:23 * kashyap waves 14:01:27 <johnthetubaguy> o/ 14:01:27 <dansmith> o/ 14:01:30 <lyarwood> o/ 14:01:31 <cdent> o/ 14:01:32 <dims> \o/ 14:01:43 <mriedem> #link agenda https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting 14:01:53 <mriedem> #topic release status 14:01:58 <raildo> o/ 14:02:02 <moshele> hi 14:02:02 <BobBall> \o 14:02:05 <mriedem> according to the ML thread from last week, mitaka should be released today 14:02:17 <alex_xu> o/ 14:02:25 <mriedem> "(8:55:34 AM) dhellmann: Ok, I'm going to find a glass of wine to celebrate." 14:02:28 <mriedem> must have already happened 14:02:35 <johnthetubaguy> #link https://github.com/openstack/nova/releases/tag/13.0.0 14:02:53 <mriedem> ok 14:02:57 <mriedem> yay 14:02:58 <ndipanov> wooo 14:03:15 <mriedem> #topic bugs 14:03:24 <mriedem> #link check queue gate status http://status.openstack.org/elastic-recheck/index.html 14:03:32 <mriedem> i'm not aware of any new major blockers, 14:03:34 <markus_z> no crits AFAIK and no 14:03:48 <mriedem> vexxhost was disabled this week because 70% of job timeouts were happening on vexxhost 14:03:55 <markus_z> *regressions 14:04:24 <mriedem> #link new bugs that need triage https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New&orderby=-datecreated&start=0 14:04:35 <mriedem> i see we must have landed the tags api 14:04:40 <mriedem> there is a docs bug 14:04:53 <mriedem> it's only been what, since juno? 14:05:33 <mriedem> #link 3rd party CI status http://ci-watch.tintri.com/project?project=nova&time=7+days 14:05:50 <mriedem> no news here really, xen ci's were having issues earlier in the week, seems like that's been sorted out 14:06:00 <mriedem> except the latent libxenlight thing that fails most of the xenproject ci runs 14:06:25 <mriedem> #topic reminders 14:06:31 <BobBall> I think the libxenlight bug is waiting on some reviews to go through 14:06:38 <mriedem> BobBall: link? 14:07:15 <BobBall> I believe it's the two patches at https://review.openstack.org/#/c/201257/ 14:07:16 <markus_z> mriedem: Wanna say some words about the "bug cleanup day" we talked about at Tuesday? 14:07:25 <mriedem> markus_z: that was next 14:07:29 * bauzas waves a bit late 14:07:32 <BobBall> And 'more explanation' is needed :) 14:07:39 * BobBall will poke anthonyper 14:07:57 <mriedem> #help review https://review.openstack.org/#/q/topic:bug/1461642+status:open to fix latent xenproject CI failures 14:08:02 <thomasem_> o/ 14:08:04 * kashyap would be missing the bug cleanup day on 18th; will be traveling. Not that I couldn't do it on another day... 14:08:27 <mriedem> kashyap: feel free to do it anytime you have free time 14:08:31 <mriedem> which brings me to 14:08:32 <mriedem> #info Launchpad bug spring cleaning day Monday 4/18: http://lists.openstack.org/pipermail/openstack-dev/2016-April/091456.html 14:08:40 <mriedem> just a reminder 14:08:40 <bauzas> mriedem: all: Mitaka is officially released https://review.openstack.org/#/c/302452/ 14:08:50 <mriedem> bauzas: yup, old news 14:08:59 <kashyap> mriedem: Yeah, I'm subscribed to relevant tags. Discipline is missing 14:09:15 <mriedem> to reiterate, the bug cleanup thing on the 18th is not a bug squashing day, 14:09:19 <mriedem> it's a cleanup launchpad day 14:09:29 <mriedem> we have a lot of old garbage in there 14:09:43 <mriedem> which makes finding the actual real bugs that need attention difficult 14:09:48 <bauzas> what could we do for bugs provided like 1yr ago ? 14:10:07 <bauzas> asking the bug reporter to check again if the bug is there for master ? 14:10:09 <mriedem> bauzas: they might not be relevant anymore 14:10:23 <bauzas> mriedem: I agree, I just wonder the direction we could say 14:10:29 <mriedem> if there is not enough info and they haven't retried on newer code, then it's incomplete 14:10:42 <bauzas> like "Incomplete, please retry the problem within master" 14:10:48 <mriedem> if it's already incomplete for >x days (i forget the number, 60?), then i think we move to invalid 14:10:49 <bauzas> okay, LGFM 14:10:57 <bauzas> 90 AFAIK 14:11:00 <mriedem> there is a tab for stale incomplete stuff though 14:11:05 <mriedem> it's in markus_z's dashboard 14:11:14 <mriedem> anyway, let's talk about that when it gets closer to the date 14:11:27 <mriedem> #link New review focus list: https://etherpad.openstack.org/p/newton-nova-priorities-tracking 14:11:39 <mriedem> subteams - make sure your stuff is up to date in ^ 14:11:44 <mriedem> and limit it to <10 changes per subteam 14:11:44 <danpb> FYI in Fedora, we bulk close all old bugs reported against outdated release when it goes EOL 14:11:46 <mriedem> code and specs 14:11:58 <danpb> and tell people to re-open it if they still have a problem with newer version 14:12:02 <mriedem> danpb: yeah, but fedora goes EOL pretty fast doesn't it? 14:12:03 <danpb> this avoids bugs jus sitting there forever 14:12:20 <danpb> mriedem: it releases every 6 months just like openstack 14:12:34 <kashyap> Yeah, that's been the best way Fedora packagers cope with the volume 14:12:38 <mriedem> does it maintain stable releases for a year though? 14:12:39 <danpb> so effectively every 6 months we kill off bugs that are 1.5 years old 14:12:48 <mriedem> ok 14:13:10 <danpb> (6 months of it being rawhide + 12 months of release lifetime after GA) 14:13:14 <markus_z> mriedem: I'll make a query for that and answer on the ML post 14:13:15 <johnthetubaguy> it does seem a reasonable culling cycle 14:13:16 <mriedem> ftr, i have no problem with marking a bug invalid if it was reported against juno or kilo and the reporter hasn't recreated against master 14:13:33 <bauzas> yeah we could do that 14:13:43 <mriedem> however, i expect most deployments right now are on kilo and liberty 14:13:53 <mriedem> so i don't think we can just invalidate bugs reported against liberty outright 14:13:59 <dansmith> you'd have to do it by date 14:14:03 <dansmith> because unlike fedora, 14:14:05 <bauzas> we could support bugs down to Kilo and invalid the older ones 14:14:12 <dansmith> most people are just rolling to something as it becomes EOL :/ 14:14:22 <kashyap> (To put another way: Once N+2 is released, 'N' goes End-of-Life. And, all bugs (that are not solved) reported against 'N' are closed, with a request to re-test them on N+2, and re-open it if the issue persists.) 14:14:25 <johnthetubaguy> yeah, we don't really have the target, so date seems the best approach 14:14:34 <danpb> mriedem: sure, for as long as upstream maintain a stable branch we shouldn't kill bugs against it 14:15:10 <mriedem> i'm glad to see there is interest in this :) but let's move on and get into details closer to the actual date 14:15:12 <danpb> if vendors want to maintain stable branches downstream though for long, its their responsibility to deall with bugs downstream 14:15:18 <mriedem> but totally feel free to start cleaning up stuff now 14:15:40 <mriedem> #link Draft Newton release schedule is up: http://releases.openstack.org/newton/schedule.html 14:15:48 <mriedem> #info Get specs re-proposed for Newton if they were approved but not implemented (completed) in Mitaka. This is the list we're using before the summit, everything else that's new is on freeze until after the summit. 14:15:55 <mriedem> #link Open re-proposed specs: https://review.openstack.org/#/q/project:openstack/nova-specs+status:open+previously-approved 14:16:14 <mriedem> #info We already have 43 approved blueprints: https://blueprints.launchpad.net/nova/newton - 3 are completed, 6 have not started 14:16:49 <mriedem> i almost want to say, if you had a blueprint re-approved for newton and do'nt have code up by the summit, we yank it 14:17:06 <mriedem> b/c that means you've had at least 2 chances to get your code up for an approved spec and failed to do so 14:17:18 <mriedem> but, we can hash that out at the summit 14:17:35 <mriedem> #help https://wiki.openstack.org/wiki/Nova/BugTriage#Weekly_bug_skimming_duty Volunteers for 1 week of bug skimming duty? 14:17:50 <mriedem> #link https://wiki.openstack.org/wiki/Nova/BugTriage#Weekly_bug_skimming_duty 14:18:25 <mriedem> i'd ask that the core team help check new bugs every so often, daily or every other day, it's easy to pick off at least one of the new bugs per day, i invalidated 3 new ones in an hour last night 14:18:44 <mriedem> #link Stable branch status: https://etherpad.openstack.org/p/stable-tracker 14:18:55 <mriedem> nothing new here impacting nova 14:19:02 <mriedem> #link stable/mitaka: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/mitaka,n,z 14:19:16 <mriedem> i'll go through and start dropping my -2s on stable/mitaka backports now that we're live 14:19:27 <mriedem> #link stable/liberty: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/liberty,n,z 14:19:36 <mriedem> there are some +2ed stable/liberty backports that could use some love 14:19:49 <mriedem> #link stable/kilo: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/kilo,n,z 14:20:06 <bauzas> I guess kilo will be discussed during the summit stable session ? 14:20:06 <mriedem> we need to probably make a better effort to start killing some of the stable/kilo stuff off now 14:20:11 <mriedem> bauzas: yeah 14:20:16 <bauzas> okay 14:20:19 <mriedem> i've been dragging my feet on nixing some of the stable/kilo reviews 14:20:44 <mriedem> ok, that's it for reminders (whew) anything have anything for reminders? 14:20:46 <mriedem> *anyone 14:20:56 <mriedem> #topic Stuck Reviews 14:21:08 <mriedem> there was nothing in the agenda 14:21:15 <mriedem> #topic Open discussion 14:21:23 <mriedem> #link Austin Design Summit ideas: https://etherpad.openstack.org/p/newton-nova-summit-ideas 14:21:29 <mriedem> #info There is a draft schedule at the bottom of the newton-nova-summit-ideas etherpad. Some of the sessions might happen on the Tuesday cross-project day though, so Nova will hold off on formalizing the design summit session schedule until the week of 4/11. 14:21:45 <mriedem> i believe the tuesday xp sessions should be formalized today 14:21:54 <mriedem> so early next week the nova schedule will get formalized 14:22:03 <mriedem> wed is pretty solid already 14:22:09 <mriedem> We have space for two sessions where we haven't decided content, so get your input into the etherpad this week if you have ideas. 14:22:16 <mriedem> ^ is for thursday 14:22:39 <mriedem> bauzas suggested a session on pci/numa/fpga and high-performance guests 14:22:48 <bauzas> yeah 14:23:00 <mriedem> if you want people to consider that, get the details in the etherpad 14:23:06 <bauzas> so, we have some 3rd party CI for PCI that I'd like to get a better shape 14:23:23 <bauzas> and also the FPGA discussion seems promising 14:23:33 <bauzas> plus of course the NUMA things 14:23:48 <mriedem> so all of the things that we constantly regress and don't test very well 14:23:52 <bauzas> so probably kind of an opportunity to sit down and see what we can work for Newton 14:23:53 * danpb apologizes for not attending the summit this time 14:24:09 <ndipanov> I think by far most interesting thing to talk about there from code pov is PCI stuff 14:24:17 <ndipanov> there's plenty to improve there 14:24:25 <johnthetubaguy> vGPU and FPGA kinda relate to that as well, I guess 14:24:32 <bauzas> "room for improvement" 14:24:44 <bauzas> johnthetubaguy: yeah, hence my wonders I made to mriedem 14:24:45 <mriedem> so i'm hearing technical debt cleanup 14:24:58 <ndipanov> bauzas, ok fair enough it's a pile of s*it 14:25:00 <mriedem> i'm pro cleaning up technical debt when it comes to NFV stuff 14:25:02 <johnthetubaguy> flavor extra spec objectification could be part of that story I guess 14:25:19 <bauzas> honestly, I liked the live-mig subteam approach 14:25:22 <mriedem> if this is about piling in more untested NFV things, i'm less interested 14:25:30 <johnthetubaguy> not worthy of a full sessions, but I think sfinucan was keen to look at flavor extra specs 14:25:51 <danpb> flavour extra specs objectification will be even more horrific than the image meta work 14:25:57 <mriedem> anyway, ndipanov + bauzas - if you have some specific things to talk about, please add them to a section in that etherpad 14:26:03 <johnthetubaguy> danpb: it will, ack 14:26:17 <bauzas> mriedem: I could just leave my thoughts, but if noone takes the ball, then meh :) 14:26:21 <mriedem> johnthetubaguy: yeah, flavor extra specs objects are currently in the API section of the etherpad bug i'm not sure why 14:26:25 <danpb> a first step is probably auditing the code to try and build a list of all stuff we use in flavour extra specs 14:26:29 <mriedem> bauzas: that's fine, proposals are free 14:26:33 <bauzas> the idea is more to see people gathering around and agreeing to work on a same direction :) 14:26:35 <dansmith> mriedem: because we need to make api changes to do it right, IMHO 14:26:37 <danpb> so that we have an idea ofthe scale of the problem 14:27:04 <mriedem> ok, so we have 2 sessions for API, back to back 14:27:17 <dansmith> two for api? 14:27:19 <mriedem> mostly for default policy in code and discoverability 14:27:41 <mriedem> the api section in the etherpad is pretty full 14:27:44 <mriedem> too full for one sessoin 14:28:18 <mriedem> so my point is, if we want to go over flavor extra specs objects, it's probably going to be it's own session, if it's really hairy 14:28:19 <dansmith> policy and capabilities I guess are the big ones there 14:28:37 <dansmith> I think those three things are their own sessions 14:28:54 <edleafe> easily 14:28:55 <johnthetubaguy> if we have the space, I am +1 that 14:28:55 <mriedem> yeah, so maybe that's a candidate for one of the thurs afternoon slots 14:28:56 <diana_clarke> Is it possible for people not attending summit to listen in to these sessions? 14:28:57 <dansmith> flavor stuff should be 5pm on friday after everyone is half into their first beer 14:29:21 <mriedem> diana_clarke: i don't know what the rooms are going to be like for AV 14:29:36 <dansmith> historically that has been hard, although it depends on what the rooms are like 14:29:37 <mriedem> diana_clarke: passing microphones doesn't really work 14:29:41 <edleafe> diana_clarke: unfortunately, generally not 14:29:56 <cdent> diana_clarke: I've tried that before and it just doesn't work, even if the tech is good 14:29:59 <johnthetubaguy> diana_clarke: generally it sucks, its sorta possible to have one remote person kinda join the session, but other ways have always failed 14:30:05 <dansmith> the nova room is usually very large, and thus not super doable 14:30:26 <mriedem> there will be etherpads though and notes in those 14:30:40 <edleafe> it's hard to hear what's being said sometimes, even when you're in the room 14:30:52 <dansmith> especially when bauzas goes on and on about cheese 14:30:56 <bauzas> :) 14:30:56 <alaski> I don't think the policy in code work will need a lot of discussion, so it could probably roll into a single session with capabilities 14:31:11 <johnthetubaguy> diana_clarke: yeah, adding comments on the etherpad before the session, and reading the summary afterwards is "state of the art" really 14:31:41 <johnthetubaguy> alaski: depends if we wonder towards discovery though 14:31:56 <mriedem> yeah i'd prefer to leave extra room for new things 14:32:02 <dansmith> I think we can easily hit an hour on that topic :) 14:32:06 <dansmith> I plan to throw things 14:32:13 <alaski> fair enough 14:32:34 <alaski> johnthetubaguy: I'm not sure how discovery and capabilities differ, but the API side is definitely a big topic 14:32:35 <mriedem> i think the neutron and cinder sessions will also be not enough for 40 minutes, but i don't really want to do 2 sessions for either of those 14:32:38 <bauzas> attending remotely midcycles is already a challenge, I sincerely doubt of any success for a fishbowl session :( 14:32:53 <johnthetubaguy> alaski: oops, true 14:33:11 <mriedem> ok, moving on 14:33:17 <mriedem> (moshele): specless blueprint for adding infiniband support to the ironic driver and ironic service: https://blueprints.launchpad.net/nova/+spec/ironic-infiniband-support 14:33:30 <mriedem> moshele: do you want to talk about this? 14:33:44 <moshele> yes 14:34:06 <moshele> so this is a change need in nova ironic to support infiniband in ironic 14:34:11 <markus_z> mriedem: I added one too (last minute) 14:34:45 <moshele> the change is very small for doing converting Infinband GUID to Mac 14:35:13 <mriedem> moshele: the nova change itself is small, 14:35:19 <mriedem> what worries me is the dependency chain 14:35:22 <dansmith> how do you make that translation? 14:35:25 <mriedem> there are 3 dependent ironic projects 14:35:41 <moshele> The import one is ironic 14:36:09 <moshele> the ironic-inspector and agent or not the dependency here 14:36:12 <mriedem> dansmith: the code change in nova https://review.openstack.org/#/c/266540/ 14:36:25 <mriedem> moshele: no, but they are dependencies for the ironic spec, 14:36:28 <mriedem> which is a dependency for the nova change 14:37:06 <dansmith> oh mah 14:37:06 <moshele> they just to be able to discover inifinband automatically 14:37:18 <dansmith> just take the bottom chunk of the uuid? 14:37:26 <moshele> only this change https://review.openstack.org/#/c/264263/ 14:37:38 <mriedem> wow 14:37:40 <mriedem> that's not small 14:38:02 <mriedem> moshele: so, i'm basically -2 on this until the ironic stuff is at least +2 14:38:12 <mriedem> given the large dep tree on ironic here 14:38:32 <moshele> mriedem: fine by me, but I don't need spec for nova right? 14:39:15 <mriedem> given the smallish change in nova it doesn't seem that a spec is required, 14:39:23 <mriedem> it's enabling a feature in a single virt driver for a single vendor 14:40:07 <mriedem> anyone else think this needs a spec or not? 14:40:40 <mriedem> nope, ok, so specless it is 14:40:52 <moshele> ok cool 14:40:55 <mriedem> i'll add a comment to the bp after the meeting about need to see approvals on the ironic parts before nova moves ahead 14:41:03 <mriedem> markus_z: https://blueprints.launchpad.net/nova/+spec/linux-ficon-support go! 14:41:15 <markus_z> The main part is done in cinder and os-brick 14:41:21 <danpb> IMHO i guess it depends on what the scope of the integration in nova ironic is ? 14:41:38 <markus_z> we need a new libvirt volume driver which does the connect/disconnect 14:41:40 <dansmith> danpb: patch above 14:41:46 <mriedem> markus_z: i see the cinder bp is approved https://blueprints.launchpad.net/cinder/+spec/linux-ficon-support 14:41:47 <dansmith> oh sorry heh 14:41:49 <markus_z> That's it basically. 14:41:50 <mriedem> even though the cinder spec isn't 14:42:01 <johnthetubaguy> mriedem: +1 on specless for the iroinc change, and the ironic approvals needs 14:42:44 <mriedem> markus_z: ok, so just a new libvirt volume wrapper to an os-brick connector, that is specless bp then 14:42:51 <mriedem> at least that's how we've treated these in the past, i'm fine with that 14:42:58 <markus_z> yep, that's all we need for that 14:43:05 <johnthetubaguy> yeah , +1 for specless os-brick integration 14:43:21 <markus_z> cool, thanks 14:43:26 <mriedem> markus_z: ok, can you or stefan get the cinder spec thing resolved? the bp is approved but the spec isn't, i'm not sure it needs a cinder spec 14:43:49 <markus_z> mriedem: Yep, will do 14:43:51 <mriedem> alright, anyone else have anything for open discussion? 14:44:15 <mriedem> alright, thanks for coming everyone 14:44:19 <mriedem> #endmeeting