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