14:00:11 <mriedem> #startmeeting nova 14:00:11 <openstack> Meeting started Thu Jun 2 14:00: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:00:12 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:15 <openstack> The meeting name has been set to 'nova' 14:00:23 <markus_z> o/ 14:00:23 <alaski> o/ 14:00:24 <takashin> o/ 14:00:27 <lyarwood_> o/ 14:00:27 <diana_clarke> o/ 14:00:27 <diga> o/ 14:00:29 * kashyap waves 14:00:32 <gagehugo> woo 14:00:33 <andrearosa> hi 14:00:33 <lbeliveau> o/ 14:00:36 <ametts> o/ 14:00:39 <scottda> hi 14:00:39 <rlrossit> o/ 14:00:46 <hshiina> o/ 14:00:54 <dansmith> ohai 14:00:55 <bauzas> \o 14:00:56 <mriedem> #link agenda https://wiki.openstack.org/wiki/Meetings/Nova 14:01:00 <gibi> o/ 14:01:29 <mriedem> missing some people but i don't want to ping, so let's get started 14:01:35 <mriedem> #topic release news 14:01:42 <mriedem> #link Newton release schedule: https://wiki.openstack.org/wiki/Nova/Newton_Release_Schedule 14:01:47 <mriedem> #info June 2 (today): newton-1, non-priority spec approval freeze 14:02:00 <sdague> o/ 14:02:12 <mriedem> so today is going to be n-1, i or bauzas will push that up to the releases repo after this meeting 14:02:23 <mriedem> today is also the last day before non-priority spec approval freeze 14:02:42 <mriedem> so i plan on spending what time i have in between meetings doing spec reviews on things that are already close to being approved 14:03:07 <mriedem> any questions about that? 14:03:19 <bauzas> what are we doing at the end of that day ? :) 14:03:19 <mriedem> #topic bugs 14:03:36 <bauzas> stop accepting specs for those which aren't prio ? :) 14:03:41 <mriedem> bauzas: i thought about that yesterday, in the past we haven't -2d anything i don't think 14:03:52 <bauzas> sorry for rushing into an open door... 14:03:54 <mriedem> bauzas: yeah i think it's just the nova-specs core team stops approving things 14:04:06 <mriedem> procedural -2 on 100+ specs isn't going to be fun 14:04:10 <PaulMurray> o/ 14:04:21 <mriedem> we just stop approving 14:04:51 <markus_z> #info no criticals, 43 untriaged bugs 14:05:12 <bauzas> mriedem: I'm fine with that, we can still review, just preventing those to be merged 14:05:12 <markus_z> bauzas solved the one crit from Monday 14:05:23 <mriedem> oslo.i18n something or other? 14:05:25 <mriedem> i saw that in the ML 14:05:29 <bauzas> not really 14:05:32 <bauzas> a cinderclient 14:05:34 <sdague> mriedem: it's going to be super hard to find the specs that are still active if there isn't some review marking on them 14:05:53 <bauzas> cinderclient was just redefining the locales :) 14:06:13 <mriedem> sdague: do you have any suggestions besides global -2? 14:06:26 <sdague> mriedem: nope 14:06:38 <mriedem> once we get the specs repo setup for ocata then people can move them 14:06:46 <mriedem> but historically that doesn't happen until after the midcycle 14:07:04 <sdague> danpb has a review up for it already 14:07:10 <mriedem> fwiw i'm fine with blanket -2 until ocata specs open up 14:07:20 <sdague> https://review.openstack.org/#/c/324397/ 14:07:52 <dansmith> people can submit against ocata without any sort of formal opening 14:08:09 <mriedem> so filter out open specs which aren't in the specs/newton/approved dir 14:08:11 <mriedem> in gerrit 14:08:24 * bauzas shrugs 14:08:26 <dansmith> after today, 14:08:30 <sdague> mriedem: sure, that's fine. 14:08:38 <dansmith> we're mostly going to be doing targeted reviews of specs that are for prios, right? 14:08:42 <mriedem> yes 14:08:46 <dansmith> so I would expect that means that: 14:08:48 <mriedem> which is why i'm not really concerned 14:08:53 <dansmith> we don't go trolling through gerrit looking for them, 14:08:57 * alex_xu waves late 14:09:06 <dansmith> but instead are using a prio list or pings from subteam people to get those things reviewed 14:09:14 <mriedem> dansmith: yes that's what i expect 14:09:19 <mriedem> if they are priority they will be brought up 14:09:22 <dansmith> so -2ing them doesn't seem that important as long as we have consistent understanding across reviewers 14:09:33 <mriedem> in other words, i'm not goin to be looking for things in nova-specs until ocata opens up 14:09:38 <dansmith> aye 14:09:51 <sdague> ok 14:09:52 <bauzas> we can just -2 and ask the subteam to claim un--2'ing if they think it's a prio 14:10:02 <mriedem> people can move them to ocata, but i don't want them thinking they can ping for reviews 14:10:09 <dansmith> bauzas: that's the opposite of what I just said i think 14:10:30 <bauzas> either way, I'm not super convinced, your call 14:10:55 <mriedem> how about we table it for after the meeting and i'll send the decision to the dev list afterward? 14:11:17 <mriedem> #action mriedem to send an email to the dev list about what people should do or expect with non-priority specs that missed the deadline for newton 14:11:39 <mriedem> so bugs :) 14:11:48 <mriedem> 43 is quite a few new untriaged bugs 14:12:02 <sdague> 46 14:12:05 <mriedem> that list is better <20 14:12:40 <mriedem> #help need help with bug triage https://goo.gl/sB9QgZ 14:13:07 <mriedem> but nothing holding up n-1 14:13:11 <mriedem> so we'll still do that today 14:13:25 <mriedem> gate status seems to be ok 14:13:34 <bauzas> it was a bit funky by monday 14:13:56 <mriedem> http://status.openstack.org//elastic-recheck/data/uncategorized.html is mostly unusable now 14:13:57 <bauzas> folks, just don't take vacations 14:13:58 <mriedem> :( 14:14:16 <mriedem> third party ci status - any news from anyone here? 14:14:20 <mriedem> i saw something in the ML about nfv ci 14:14:23 <mriedem> failing shelve tests 14:14:38 <mriedem> jaypipes: did anyone make any progress on sorting that out? i saw the tests were just disabled 14:14:51 <bauzas> citrix CI was a bit unhappy too, but that seems to be solved 14:15:29 <mriedem> alright, anyway, sounds like a legit bug that the intel NFV CI found 14:15:36 <mriedem> with cpu pinning and shelve/unshelve 14:15:47 * mriedem hopes someone that cares about that is working on a fix 14:16:06 <mriedem> #topic reminders 14:16:13 <mriedem> #link Newton review focus list: https://etherpad.openstack.org/p/newton-nova-priorities-tracking 14:16:20 <mriedem> We have 73 approved blueprints: https://blueprints.launchpad.net/nova/newton - 7 are completed, 9 have not started, 3 are blocked 14:16:21 <lbeliveau> I know moshele wanted to have a look, I guess we'll take care of it 14:16:30 <mriedem> lbeliveau: ok 14:17:04 <mriedem> so we have a lot of approved blueprints already - keep that in mind before requesting exceptions 14:17:18 <mriedem> nova-specs cores: when you approve a spec, remember to approve the blueprint in launchpad; blueprint owners: ping someone from the nova-specs core team if you have a spec approved but the blueprint is not yet approved. 14:17:53 <mriedem> i've noticed several specs that are approved but the bits in LP aren't adjusted like the target series or marking it approved, those things generally get sorted out when reviewing the code, but it'd be better to avoid that 14:18:18 <mriedem> #help https://wiki.openstack.org/wiki/Nova/BugTriage#Weekly_bug_skimming_duty Volunteers for 1 week of bug skimming duty? 14:18:36 <mriedem> looks like we have people for this week and next 14:18:37 <diga> mriedem: Hi, I have registered new BP - https://blueprints.launchpad.net/nova/+spec/display-host-hypervisor-numa-topology 14:18:45 <mriedem> diga: this isn't the time to bring that up 14:18:49 <mriedem> wait for open discussion 14:18:50 <diga> okay 14:19:12 <mriedem> moving on 14:19:16 <mriedem> #topic stable branch status 14:19:23 <mriedem> #info We'll be pushing a release request for liberty and mitaka today or early next week. Ping someone from the nova-stable-maint team if you need to get something into that release. 14:20:06 <mriedem> i'll probably do a pass through stable branch reviews tomorrow 14:20:09 <mriedem> there are a few for liberty 14:20:13 <mriedem> there are a lot for mitaka 14:20:37 <mriedem> but we can begin -2ing liberty things that aren't security or critical regressions 14:20:50 <mriedem> #topic subteam highlights 14:21:00 <mriedem> alaski: any highlights from the cells v2 meeting? 14:21:17 <alaski> not much to note this week. work is progressing on multiple fronts 14:21:22 <alaski> mostly around db migrations 14:21:48 <mriedem> ok, good 14:21:54 <mriedem> anything else? 14:21:55 <alaski> there was talk of proposing a change to instance tags 14:22:09 <alaski> but that's not up yet 14:22:17 <alaski> that's it 14:22:20 <mriedem> ok, thanks 14:22:30 <mriedem> edleafe: highlights from the scheduler meeting? 14:22:44 <dansmith> alaski: not much to note? the patches to move inventory to the api db merged 14:22:56 <dansmith> that was like almost then end of me, frustration-wise :D 14:23:23 <alaski> dansmith: it wasn't mentioned in the meeting though, so it didn't count :) 14:23:28 <bauzas> dansmith: we should see what's next to review :) 14:23:31 <bauzas> alaski: I did :p 14:23:39 <dansmith> alaski: but I was pulled off on something else and couldn't! but but! 14:23:43 <bauzas> alaski: but you didn't followed up 14:23:57 <alaski> bauzas: ahh, okay 14:24:11 <mriedem> so much love and thanks to dansmith for a herculian effort there 14:24:13 <alaski> dansmith: it was a huge step forward, yes 14:24:31 <mriedem> was there a scheduler meeting this week? 14:24:41 <mriedem> cdent: edleafe: bauzas: jaypipes: ? 14:24:48 <bauzas> mriedem: yup 14:24:55 <diana_clarke> edleafe is at pycon 14:25:03 <cdent> I was not in attendance (monday holiday) 14:25:18 <mriedem> bauzas: anything you want to mention? 14:25:42 <mriedem> i saw cdent's email in the dev list about sticky wickets 14:25:46 <bauzas> mriedem: oh no, nevermind, my brain confused me 14:25:48 <mriedem> haven't read the full response from jay 14:25:53 <bauzas> monday was a day off 14:26:01 <mriedem> ok, moving on then 14:26:02 <bauzas> for UK and US + pytohn 14:26:05 <bauzas> pycon 14:26:05 <cdent> mriedem: we figured out more stick wickets yesterday in conversation with the ever suffering dansmith 14:26:17 <cdent> jay has a summarizing email in progress (he said earlier today) 14:26:25 <mriedem> ok 14:26:34 <dansmith> I should get an oil painting of myself struggling to hold up the entire world 14:26:35 <mriedem> baremetal sticky wickets? 14:26:48 <mriedem> dansmith: new friday nick is john galt 14:26:49 <cdent> mriedem: no, the baremetal stuff is yet other wickets 14:26:53 <dansmith> to match my impression of my heroism 14:26:59 <dansmith> mriedem: heh, nice 14:27:10 <mriedem> ok moving on 14:27:20 <mriedem> PaulMurray: live migration highlights? if there was a meeting 14:27:23 <PaulMurray> The main talking point was around new version of libvirt not working with gate64 cpu model used in CI 14:27:41 <PaulMurray> sdague, tdurakov danpb did something about it 14:27:54 <mriedem> yup, should be fixed now, and the nova change was backported to mitaka 14:27:54 <PaulMurray> since 14:28:12 <PaulMurray> There was also a discussion kicked off about state machines 14:28:12 <sdague> mriedem: the backport still needs to be approved 14:28:19 <mriedem> sdague: as does the d-g change https://review.openstack.org/#/c/320925/ 14:28:19 <sdague> it failed unit tests on the first go 14:29:28 <mriedem> i haven't gotten to the dev list thread on the state machine thing 14:29:39 <PaulMurray> there is a spec by tangchen 14:29:50 <PaulMurray> proposing a state machine for migration status 14:29:59 <PaulMurray> I think the conclusions is everyone likes the idea 14:30:03 <PaulMurray> but it needs more thought 14:30:13 <PaulMurray> and seperation from status given in API 14:30:29 <PaulMurray> so spec is not approved as of now 14:30:30 <mriedem> maybe something for the midcycle 14:30:39 <PaulMurray> I think so, worth pursuing 14:30:43 <PaulMurray> in some form 14:30:48 <alaski> +1 14:31:10 <mriedem> so given the risk and complexity involved, i'm thinking it's a no go for newton, 14:31:15 <mriedem> discuss at the midcycle in detail, 14:31:18 <mriedem> then shoot for ocata 14:31:18 <sdague> mriedem: ++ agree 14:31:47 <sdague> as we want to make sure we've all thought it through before we potentially change what the users see 14:31:48 <PaulMurray> that's it (appart from usual progress on image cache backend etc) 14:32:15 <PaulMurray> I think there are upgrade issues as well that aren't called out 14:32:28 <mriedem> goody 14:32:35 <mriedem> ok, thanks paul 14:32:44 <mriedem> sdague: alex_xu: api meeting highlights? 14:33:30 <sdague> the v2 legacy code just got deleted 14:33:35 <mriedem> \o/ 14:33:40 <alex_xu> yes \o/ 14:33:42 <mriedem> oomichi: thanks for working on that 14:34:30 <sdague> also we talked about the user_id policy work around quite a bit 14:34:36 <sdague> https://review.openstack.org/#/c/324068/ is the spec that emerged from that 14:35:19 <mriedem> ok, that falls into the priority camp 14:35:21 <sdague> at slow but steady progress on the api-ref updates - http://burndown.dague.org/ 14:35:24 <mriedem> so not restricted to the deadline today 14:36:00 <sdague> I think that's about it 14:36:23 <mriedem> ok, and we have consensus on limit/marker specs in the dev list 14:36:25 <mriedem> so that's good 14:36:33 <mriedem> and a few approved for adding those 14:36:43 <sdague> yep 14:37:07 <mriedem> ok thanks 14:37:12 <mriedem> lbeliveau: pci/sriov meeting highlights? 14:37:19 <lbeliveau> we are closing on resize bug https://review.openstack.org/#/c/307124/19 14:37:25 <lbeliveau> jaypipes and dansmith are reviewing 14:37:40 <lbeliveau> cold migration fix was redesigned based on resize patch https://review.openstack.org/#/c/242573/21 14:37:59 <lbeliveau> that's it 14:38:34 <mriedem> ok, let's make sure those are in the newton review priorities etherpad 14:38:44 <mriedem> thanks for the focus there 14:38:54 <mriedem> gibi: notifications meeting highlights? 14:38:57 <lbeliveau> I'll put them in the etherpad 14:39:00 <gibi> so regarding notifications I have 4 things 14:39:05 <gibi> transformation spec merged, code is under subteam review 14:39:05 <gibi> #link https://review.openstack.org/#/q/branch:master+topic:bp/versioned-notification-transformation-newton 14:39:12 <gibi> json schema generation spec merged in oslo, implementation ongoing 14:39:12 <gibi> #link https://review.openstack.org/#/c/318950/ 14:39:25 <gibi> I've create a wiki listing every notification that needs to be transformed, with some instructions how to get started. 14:39:35 <gibi> #link https://wiki.openstack.org/wiki/Nova/VersionedNotificationTransformation 14:39:44 <gibi> I will post it to ML later today 14:39:52 <mriedem> gibi: hook up with auggy on that 14:40:06 <mriedem> sounds like low hanging fruit that can get worked into anything she's doing with mentoring stuff 14:40:25 <gibi> yes, half of the them are low hanging. I will ping auggy 14:40:29 <gibi> johnthetubaguy introduced some OSIC people on the subteam meeting. They are eager to help with the transformation. 14:40:53 <mriedem> ok, cool 14:41:04 <gibi> and the last thing 14:41:04 <mriedem> and yeah advertizing in the ML is a good idea 14:41:15 <gibi> There is one spec close to merge (already has +2) about transforming and enhancing keypair notifications: #link https://review.openstack.org/#/c/300942/ Versioned notification for keypairs 14:41:37 <gibi> besides that notifications are in good shape for n-1 14:41:52 <mriedem> gibi: ok, would be good to see +1s from the notifications subteam on that spec 14:42:08 <gibi> mriedem: ok 14:42:16 <rlrossit> added myself to take a look later today 14:42:30 <mriedem> thanks guys 14:42:34 <mriedem> #topic stuck reviews 14:42:35 <gibi> that's it 14:42:42 <mriedem> there was nothing on the agenda for stuck reviews 14:43:02 <mriedem> there is a thing in the ML about exposing quiesce in the API 14:43:15 <mriedem> my feeling is that's not going to make newton 14:43:32 <mriedem> #topic open discussion 14:43:34 <lyarwood_> https://review.openstack.org/#/q/topic:bp/virt-rescue-stable-disk-devices+status:open if people have time but it's really low prio given n-1 14:43:46 * alaski has a thing for open discussion (instance-tags) 14:43:54 <mriedem> lyarwood_: was just waiting for push that this whole time 14:43:59 <mriedem> s/for/to/ 14:44:09 <lyarwood_> mriedem: waiting to hit return ;) 14:44:10 <mriedem> ok there are things in the agenda so let's hit those first 14:44:23 <mriedem> Spec libvirt-virtlogd: https://review.openstack.org/#/c/234291/ approval for Newton? Part of the needed change set is already up: https://review.openstack.org/#/c/323759/ 14:44:29 <mriedem> markus_z: ^ ? 14:44:34 <markus_z> yep, mine 14:44:55 <mriedem> markus_z: i think you can just push a new patch set to address danpb's comment 14:45:01 <mriedem> should be a quick +W from danpb and sdague then 14:45:11 <markus_z> OK, will do that 14:45:18 <sdague> it also will provide a fix for mikal's 4 year old bug 14:45:24 <sdague> so... yay for that 14:46:01 <mriedem> Specless BP for ironic trigger crash dump (inject NMI): https://blueprints.launchpad.net/nova/+spec/inject-nmi-ironic (hshiina) 14:46:11 <mriedem> Nova spec got a comment "this could be specless blueprint." from johnthetubaguy. https://review.openstack.org/#/c/229322/ 14:46:17 <mriedem> Ironic SPEC got a +2 once, expected to be merged soon. https://review.openstack.org/#/c/186700/ 14:46:46 <mriedem> so johnthetubaguy probably said specless bp since it's just virt driver feature parity 14:46:58 <mriedem> i haven't read the spec, looks like it has a dependency on ironic 14:47:18 <alaski> if it's just implementing an existing virt driver method specless seems appropriate to me 14:47:56 <hshiina> yes, just implement driver method 14:48:05 <mriedem> yeah i'm fine with that - the dependency with ironic is what's going to hold it up 14:48:18 <mriedem> hshiina: please make sure the blueprint in launchpad shows the dependency on the ironic bp 14:48:30 <hshiina> sure 14:49:02 <mriedem> i'll try to get to that one today to let you know for sure on specless 14:49:16 <mriedem> next item 14:49:18 <mriedem> Specless BP for ironic soft reboot: https://blueprints.launchpad.net/nova/+spec/soft-reboot-poweroff (hshiina) 14:49:27 <mriedem> It depends on the same Ironic SPEC as crash dump one. 14:49:34 <hshiina> it is a similar one. 14:49:41 <mriedem> yeah, virt driver feature parity 14:50:45 <mriedem> ok, i think that will probably be a trivial specless bp approval 14:50:52 <mriedem> just need to add the dep to the ironic bp in launchpad 14:50:55 <alaski> seems fine to me 14:51:20 <hshiina> ok. i will update the BPs 14:51:29 <mriedem> Specless BP for ironic boot from volume: https://blueprints.launchpad.net/nova/+spec/ironic-boot-from-volume (hshiina) 14:51:39 <mriedem> This BP can be specless. http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2015-12-07.log.html#t2015-12-07T11:43:41 14:52:07 <mriedem> "johnthetubaguysmoriya_: we need the ironic spec to merge, before we can approve the blueprint" 14:52:26 <hshiina> it is another feature. it also depneds on ironic. 14:52:28 <mriedem> depends on https://review.openstack.org/#/c/200496/ which has a +2 but a couple of -1s 14:53:10 <mriedem> hshiina: i think you can consider it soft approved for nova but it's contingent on the ironic spec/bp being approved 14:53:18 <mriedem> so the code won't land in nova until those happen in ironic 14:53:39 <mriedem> i'd expect to also see ironic CI jobs testing these features when they are available 14:53:51 <mriedem> before we merge the code in nova 14:54:01 <sdague> and it's not a priority for nova, so the clock is ticking, as it has to be in by N2 14:54:10 <mriedem> right 14:54:37 <mriedem> #action mriedem to go back through hshiina's specless ironic blueprints 14:54:51 <mriedem> ok, that's it for what's on the agenda, alaski you had something? 14:54:56 <alaski> yep 14:55:04 <hshiina> thanks for considering 14:55:24 <alaski> so while working on cellsv2 I found that instance tags can be set at any point in the instance lifecycle, including before scheduling 14:55:40 <alaski> this poses a challenge for cells where there is no actual instance before scheduling 14:55:55 <alaski> and will pose a later challenge for scheduling work which was planning to rely on instance tags 14:56:25 <alaski> these tags are the only thing that can be set on an instance before it reaches an active state, except for lock status 14:56:39 <diga> mriedem: https://blueprints.launchpad.net/nova/+spec/display-host-hypervisor-numa-topology, can we discuss on this ? 14:56:47 <alaski> I would like to require active status before allowing tags to be set 14:56:47 <mriedem> diga: in a sec 14:56:50 <diga> ok 14:57:15 <dansmith> alaski: and later maybe allow tags in the boot command itself, right? 14:57:20 <mriedem> as noted in the cells meeting yesterday, i think we can fix the instance tags thing with a bug fix 14:57:22 <alaski> dansmith: yes, exactly 14:57:31 <mriedem> passing tags on boot is an api change which requires a spec 14:57:31 <dansmith> I'm +1 on this idea 14:57:35 <dansmith> yeah 14:57:42 <mriedem> so separate, but both are good 14:57:46 <mtanino> Anyone give me a feedback for this? https://blueprints.launchpad.net/nova/+spec/virt-image-props-boot-override-via-flavor 14:57:52 <mriedem> but i think we can bug fix the immediate cells blocker 14:57:57 <dansmith> yep 14:57:57 <alaski> okay, we'll propose the change then 14:58:03 <mriedem> the royal we? 14:58:16 <alaski> heh, yeah 14:58:20 <mriedem> diga: go 14:58:25 <diga> okay 14:58:25 <mriedem> we have <2 minutes 14:58:48 <mriedem> diga: it's an api change so it requires a spec 14:58:54 <diga> I proposed this BP, but It is something we need in the host details 14:58:55 <mriedem> this isn't going to make newton 14:58:57 <diga> okay 14:59:03 <mriedem> diga: all api changes require a spec 14:59:07 <diga> okay 14:59:10 <mriedem> so work on that, but it will be targeted for ocata 14:59:14 <diga> I will submit the spec 14:59:18 <mriedem> thanks 14:59:20 <diga> sure 14:59:24 <eliqiao> mriedem: can we discuss this https://review.openstack.org/#/c/319513/9/specs/newton/approved/libvirt-perf-support.rst 14:59:44 <mriedem> mtanino: anything with extra specs at this point should be worked with the scheduler subteam 14:59:50 <mriedem> because of the host capabilities work that's going on there 15:00:04 <mriedem> mtanino: i'd suggest getting that as a topic in the nova scheduler subteam meeting agenda 15:00:06 <mriedem> for next week 15:00:11 <mriedem> eliqiao: we're out of time 15:00:16 <mtanino> mriedem: scheduler subteam, thanks for the advice 15:00:17 <mriedem> let's move to -nova 15:00:19 <mriedem> thanks everyone 15:00:23 <mriedem> #endmeeting