14:00:04 <mriedem> #startmeeting nova
14:00:05 <openstack> Meeting started Thu Jun 29 14:00:04 2017 UTC and is due to finish in 60 minutes.  The chair is mriedem. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:06 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:09 <openstack> The meeting name has been set to 'nova'
14:00:13 <dansmith> o/
14:00:14 <gibi> o/
14:00:18 <kaisers_> o/
14:00:51 * bauzas emerges from his cave
14:00:52 <takashin_> o/
14:01:08 <bauzas> too much sunlight, doh
14:01:10 <alex_xu> o/
14:01:23 <edleafe> \o
14:01:23 <efried> o/
14:01:33 <sfinucan> o/
14:01:40 <mriedem> alright i'd like to go to bed so let's get started
14:01:42 <mriedem> #link agenda https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting
14:01:51 <mriedem> #topic release news
14:02:01 <mriedem> #link Pike release schedule: https://wiki.openstack.org/wiki/Nova/Pike_Release_Schedule
14:02:09 <mriedem> #info July 27 is feature freeze (4 weeks away)
14:02:21 <mriedem> #info Blueprints: 65 targeted (-6 from last week), 62 approved, 25 (+3 from last week) completed
14:02:42 <mriedem> so we're making some slow progress on getting some blueprints done
14:02:58 <mriedem> i dropped the targeted list due to things that were blocked, not started, or just weren't going to happen in pike at this point
14:03:17 <mriedem> we still have a lot to do though
14:03:40 <mriedem> need to focus on the placement series as top priority right now probably since that's the biggest thing with the most amount of change left
14:04:03 <mriedem> anything about the release?
14:04:16 <mriedem> #topic bugs
14:04:29 <mriedem> there are no critical bugs
14:04:32 <mriedem> #help Need help with bug triage; there are 107 (+23 from last week) new untriaged bugs as of today (June 29).
14:04:45 <mriedem> so the untriaged new bugs number jumped up,
14:04:50 <mriedem> i think that's from sdague-bot
14:05:05 <mriedem> gate status - i have no idea
14:05:12 <mriedem> assume it's fine since patches are merging
14:05:21 <mriedem> 3rd party CI - again i have no idea
14:05:27 <mriedem> anyone want to mention something about bugs?
14:05:45 <mriedem> #topic reminders
14:05:52 <mriedem> #link Pike Review Priorities etherpad: https://etherpad.openstack.org/p/pike-nova-priorities-tracking
14:06:17 <mriedem> top priority right now has to be https://review.openstack.org/#/c/475448/
14:06:23 <mriedem> and the things in that series
14:06:30 <mriedem> anyone disagree?
14:06:52 <sfinucan> nope
14:07:02 <mriedem> edleafe: i know you've been reviewing that too - would be cool if you could take another pass that the latest revision today
14:07:03 <dansmith> agree
14:07:08 <edleafe> as usual, I have to update the etherpad
14:07:13 <mriedem> s/that/at/
14:07:20 <edleafe> tab is perpetually open
14:07:26 <mriedem> heh
14:07:39 <mriedem> #topic stable branch status
14:07:48 <mriedem> #link stable/ocata: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/ocata,n,z
14:07:50 <bauzas> FWIW, I'm reviewing https://review.openstack.org/#/c/475448/ now
14:07:58 <mriedem> #link stable/newton: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/newton,n,z
14:08:07 <mriedem> there is no news for stable right now
14:08:19 <mriedem> #topic subteam highlights
14:08:26 <mriedem> dansmith: cells v2 stuff this week?
14:08:32 <dansmith> nope we skipped again
14:08:39 <dansmith> summary would be that the quotas set is important
14:08:42 <dansmith> as it's holding up everything,
14:08:51 <mriedem> i see you and melwitt have been going through https://review.openstack.org/#/c/475957/
14:09:03 <dansmith> but we've been doing a bunch of reviews on those things and it's moving
14:09:04 <dansmith> aye
14:09:23 <mriedem> ok hopefully that's close
14:09:52 <mriedem> alright edleafe - scheduler
14:09:57 <edleafe> Discussed the choice to use flavor.extra_specs instead of custom Flavor attributes for specifying custom resource classes. The main reason, as stated in the spec, is that it would further tie us to flavors, making the eventual cleanup of flavors more difficult.
14:10:01 <edleafe> Otherwise it was just a recap of the outstanding reviews.
14:10:04 <edleafe> EOM
14:10:38 <mriedem> edleafe: re: https://review.openstack.org/#/c/473627/ ?
14:11:00 <edleafe> mriedem: heh, pushing as I type
14:11:23 <mriedem> ok, was just a confusing sentence for me to parse, as ^ is using extra specs
14:12:04 <edleafe> mriedem: that was the source of alex_xu's concern
14:12:36 <alex_xu> yea, new feature in the API without microversion
14:12:42 <mriedem> ok, we don't have to get into it now - i also read over that spec again today and there are some other things yet to do, like migrating some ironic data on nova-compute startup
14:12:58 <edleafe> alex_xu: the API hasn't changed
14:13:05 <mriedem> alex_xu: that's kind of how extra specs have always been
14:13:08 <mriedem> and image metadata
14:13:24 <mriedem> but yeah i don't consider this the api
14:13:25 <edleafe> alex_xu: that's one of the big problems with extra_specs
14:13:36 <alex_xu> yea, I thought we will never add new thing to the extra spec
14:13:53 <mriedem> i don't remember saying we wouldn't add new things to extra specs
14:14:11 <dansmith> well, I think we want to avoid new complex data structures in there
14:14:18 <dansmith> which we've discussedmany times
14:14:20 <mriedem> sure
14:14:24 <dansmith> however, the flavor overrides *have* to be there,
14:14:36 <dansmith> and they're simple primitive types
14:14:49 <mriedem> complex data structures like pci passthrough, right?
14:14:53 <bauzas> what's the main concern with extra specs except the fact they're not fully consistent across clouds ?
14:15:05 <dansmith> or tristate things, or json blobs, etc
14:15:06 <dansmith> we should move on and not discuss this in the meeting
14:15:20 <alex_xu> I'm stuck at the case there is no way to the API user to discover whether the current deployment support the resource_class in the extra spec or not
14:15:36 <bauzas> alex_xu: that's something we ack'd
14:15:39 <edleafe> yeah, we need to let mriedem go to bed
14:15:47 <mriedem> ok, should probably move it to the mailing list
14:15:47 <dansmith> seriously
14:15:50 <alex_xu> ok :)
14:16:08 <mriedem> there are lots of things that aren't discoverable for the user today
14:16:38 <mriedem> ok, moving on
14:16:41 <edleafe> and this is strictly operators
14:16:46 <mriedem> alex_xu: did you want to cover anything from the api meeting?
14:16:53 <alex_xu> we have short meeting
14:17:15 <alex_xu> we found the network related quotas aren't deprecated from the quota-class API yet
14:17:19 <alex_xu> #link https://bugs.launchpad.net/nova/+bug/1701211
14:17:20 <openstack> Launchpad bug 1701211 in OpenStack Compute (nova) "The network related quotas aren't deprecated in quota-class API" [Undecided,Confirmed] - Assigned to Ghanshyam Mann (ghanshyammann)
14:17:27 <alex_xu> gmann take the task
14:17:33 <mriedem> oh come on
14:17:42 <alex_xu> yea...
14:17:57 <mriedem> this is what, the 3rd microversion trying to deprecate resources hidden in quota extensions now?
14:18:04 <mriedem> 4th actually
14:18:24 <mriedem> can we roll this into the same microversion currently being worked on for server groups/members?
14:18:36 <alex_xu> yes, that patch doesn't merge yet
14:18:44 <mriedem> ok, let's do them in the same microversion then
14:18:49 <mriedem> gmann: ^
14:18:50 <alex_xu> ok, got it
14:19:04 <mriedem> thanks
14:19:08 <mriedem> gibi: notifications?
14:19:15 <gibi> No meeting this week as I was alone.
14:19:15 <gibi> The BDM patch of additional-notification-fields-for-searchlight bp needs some agreement between sfinucan and mriedem about the config option. #link https://review.openstack.org/#/c/448779/
14:19:19 <gibi> Plenty of notification transformation commits are ready for the cores to take a quick look #link https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/versioned-notification-transformation-pike+label:Code-Review%253E%253D%252B1+label:Verified%253E%253D1+AND+NOT+label:Code-Review%253C0
14:19:24 <gibi> There is an api.fault notification bug where the way forward is not clear. #link https://bugs.launchpad.net/nova/+bug/1699115
14:19:25 <openstack> Launchpad bug 1699115 in OpenStack Compute (nova) "api.fault notification is never emitted" [Medium,Confirmed]
14:19:27 <gibi> I posted details and questions about the bug to the ML: #link http://lists.openstack.org/pipermail/openstack-dev/2017-June/118639.html
14:19:30 <gibi> The rest of the status is in my weekly mail: #link http://lists.openstack.org/pipermail/openstack-dev/2017-June/118905.html
14:19:44 <gibi> that is all
14:20:00 <mriedem> ok the 2 keypair ones are approved
14:20:07 <gibi> mriedem: just saw that thanks
14:20:08 <mriedem> i'll likely have to check the bdm one later
14:20:15 <gibi> mriedem: OK
14:20:31 <mriedem> ok nova/cinder meeting,
14:20:36 <mriedem> happens in a few hours, and i won't be there
14:20:54 <mriedem> status is basically we need reviews on the 3 main changes
14:20:57 <mriedem> #help needs reviews: https://review.openstack.org/#/q/status:open+project:openstack/nova+topic:bp/cinder-new-attach-apis+branch:master
14:21:13 <mriedem> that's for swap volume, live migration and then the final one for using the new cinder api for volume attach
14:21:27 <mriedem> and then it's all rainbows and unicorns
14:21:40 <mriedem> #topic stuck reviews
14:21:55 <mriedem> there was nothing in the agenda, does anyone have anything to mention here?
14:22:00 <mriedem> i guess the bdm notifications one
14:22:14 <mriedem> anything else?
14:22:29 <mriedem> #link open discussion
14:22:33 <mriedem> oops
14:22:34 <mriedem> heh
14:22:36 <mriedem> #undo
14:22:37 <openstack> Removing item from minutes: #link open
14:22:44 <mriedem> #topic open discussion
14:22:51 <mriedem> nothing on the agenda,
14:22:58 <mriedem> does anyone have something to bring up here?
14:23:15 <dansmith> I do
14:23:24 <dansmith> I think we should have a long drawn out discussion
14:23:24 <mriedem> ok
14:23:31 <dansmith> something really juicy that takes like an hour
14:23:40 <mriedem> 37 minutes is ok
14:23:47 <efried> We could talk about trailing parentheses
14:23:52 <mriedem> how about gibi's bdm thing?
14:23:55 <dansmith> efried: that's not controversial
14:24:00 <efried> heh
14:24:09 <mriedem> gibi: can you summarize the bdm thing quick?
14:24:12 <gibi> mriedem: sure
14:24:24 <gibi> so we are adding BDM to instance.action notification
14:24:37 <gibi> but most of the cases BDM needs an extra db query to get
14:24:50 <gibi> so the original agreement in the bp was to introduce a config option
14:24:55 <mriedem> right, and instance.update for any state change
14:25:01 <gibi> right
14:25:17 <gibi> so when the config option is set we do the extra query
14:25:27 <gibi> if not set then we return null for BDM in th payload
14:25:58 <gibi> sfinucan commented on the review that this breaks the rule, do not make the API parts configurable
14:26:08 <mriedem> sure, i can see that,
14:26:10 <mriedem> however,
14:26:15 <mriedem> the end user doesn't consume notifications directly
14:26:22 <mriedem> they might indirectly via searchlight in horizon
14:26:24 <dansmith> this isn't the api, this is notifications right?
14:26:27 <mriedem> yes
14:26:31 <gibi> #link https://review.openstack.org/#/c/448779/30/nova/notifications/objects/instance.py
14:27:23 <sfinucan> So notifications aren't bound by the interop guidelines?
14:27:33 <gibi> I don't know
14:27:42 <mriedem> no
14:27:43 <dansmith> notifications are very internal to the deployment
14:27:49 <dansmith> very operator-specific in their use
14:27:51 <mriedem> right
14:28:02 <dansmith> so choosing to dump some information to save some db traffic seems appropriate to me
14:28:08 <mriedem> certain things downstream internally consume notifications, like telemetry, mistral, searchlight
14:28:14 <dansmith> s/dump/drop/
14:28:31 <mriedem> the end user doesn't see the results of those things except maybe via searchlight usage in horizon
14:28:40 <sfinucan> Ah, then I've no problem taking this route. I wasn't aware of the distinction
14:28:42 <mriedem> but i don't think horizon is exposing bdms when listing instances anyway
14:28:45 <mriedem> ok
14:29:28 <mriedem> the alternative to making it configurable is determining the small subset of notifications that we will pass bdms which only make sense for volume-related actions, like attach/detach volume, swap volume, etc - but that list is hard to define
14:29:40 <gibi> mriedem: yeah that is an alternative
14:29:49 <mriedem> e.g. migration notifications could also take those, and rebuild, etc
14:29:57 <mriedem> so let's just do the config thing
14:30:00 <sfinucan> tbh, I'm fine with configuration options
14:30:13 <gibi> OK, cool
14:30:13 <mriedem> ok, good. problem solved. :)
14:30:13 <sfinucan> YAGNI, etc.
14:30:22 <mriedem> now 30 minutes left
14:30:50 <mriedem> i think we're done
14:30:57 <mriedem> thanks everyone
14:31:00 <mriedem> #endmeeting