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