14:00:29 #startmeeting nova 14:00:32 Meeting started Thu Nov 2 14:00:29 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:33 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:36 The meeting name has been set to 'nova' 14:00:39 yeaux 14:00:39 oh hello 14:00:40 o/ 14:00:40 o/ 14:01:20 i'll wait a minute 14:01:25 \o 14:01:41 o/ 14:01:45 o/ 14:02:36 alright let's get started 14:02:39 #link agenda https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting 14:02:43 o/ 14:02:45 #topic release news 14:02:50 #link Queens release schedule: https://wiki.openstack.org/wiki/Nova/Queens_Release_Schedule 14:03:00 #info Blueprints: 59 targeted, 48 approved, 2 complete 14:03:14 i'm still working on deferring some targeted blueprints which aren't approved 14:03:42 q-2 is December 7th, so a little over 4 weeks ago 14:03:43 *away 14:03:52 #topic bugs 14:04:00 nothing critical 14:04:03 #info 12 new untriaged bugs (down 6 from last week) 14:04:17 gate status is ok, 14:04:25 we have one known issue, 14:04:44 https://review.openstack.org/#/c/517009/ 14:04:45 patch 517009 - nova - Avoid deleting allocations for instances being built 14:04:57 #link known gate failure https://launchpad.net/bugs/1729371 14:04:59 Launchpad bug 1729371 in OpenStack Compute (nova) "ResourceTracker races to delete instance allocations before instance is mapped to a cell" [High,In progress] - Assigned to Dan Smith (danms) 14:05:24 so dan's fix seems sound, except i'm seeing the warning in there show up way too much in a few jobs, and i haven't sorted out why that is yet 14:05:31 since we shouldn't hit this often 14:06:07 dan is either flying to or in sydney now, but likely half asleep and not looking at this until post-summit, so if other people can help debug it would be helpful 14:06:24 ping me in -nova if you have questions 14:06:37 there is no news for 3rd party ci 14:06:44 #topic reminders 14:06:51 Work on Forum session discussion etherpads and presentations. https://wiki.openstack.org/wiki/Forum/Sydney2017 14:07:05 anyone giving presentations should hopefully have those sorted out by now :) 14:07:24 but for the forum sessions we're still filling in agendas into the etherpads 14:07:45 #topic stable branch status 14:07:49 #link stable/pike: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/pike,n,z 14:07:54 #link Etherpad for bugs tracked for Pike backports: https://etherpad.openstack.org/p/nova-pike-bug-fix-backports 14:08:05 i wanted to point out this series 14:08:12 #help review backports https://review.openstack.org/#/q/topic:bug/1702454+status:open 14:08:26 that's needed to fix a broken API change since newton, 14:08:38 oh 14:08:44 where we added the ability to specify a host during evacuate 14:08:52 because of the request spec stuff there, that never actually worked 14:08:56 nor in ocata 14:09:09 so i'd like to get that stuff fixed before we actually EOL the newton branch 14:09:31 johnthetubaguy: ^ as stable core 14:09:55 mriedem: will you talk about EOL branch in the next point of this stable topic? 14:09:57 * johnthetubaguy makes a note to take a look 14:10:05 #link stable/ocata: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/ocata,n,z 14:10:11 #link stable/newton: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/newton,n,z 14:10:22 #info newton 14.0.9 released 14:10:27 so newton was supposed to be eol like 2 weeks ago 14:10:35 but we've had a few high severity fixes holding that up 14:10:42 and tonyb has been kind enough to oblige me 14:10:53 :) 14:11:03 so newton-eol for nova won't happen until sometime after the summit 14:11:06 Do we have en ETA? 14:11:10 ok 14:11:19 thanks for the info. 14:11:44 evrardjp: if i had to guess, i'd guess final newton release on 11/16 and then EOL the following monday 14:11:51 so 11/20 14:12:05 note that neutron has already EOL'ed it's newton branch, so we are no longer running grenade jobs on ocata changes 14:12:23 ok moving on 14:12:27 #topic subteam highlights 14:12:33 there was no cellsv2 meeting last week 14:12:36 *yesterday :) 14:12:45 edleafe: scheduler stuff? 14:12:50 All patch series moving forward. 14:12:50 Lots of bets being made on the race for the next microversion. 14:12:50 Most people getting ready for Sydney (sorry, jaypipes and efried!) 14:12:51 That's all, mate. 14:13:23 speaking of scheduler, let's get this IndexError fix in soonish https://review.openstack.org/#/c/517134/ 14:13:24 patch 517134 - nova - Fix return type in FilterScheduler._legacy_find_hosts 14:13:46 There's also a few limits issues I'm fixing 14:14:00 edleafe: in your alternate hosts series or separate? 14:14:03 Claims expects a dict, and is getting a SchedulerLimits object instead 14:14:26 Yeah - the result of switching to SchedulerLimits in the Selection object 14:14:42 ok yeah, that's because we pass the host_state.limits dict to build_and_run_instance 14:14:47 which goes to the claim 14:14:51 yep 14:14:52 well, today anyway 14:14:59 turned up in some functional tests 14:15:06 plus the other 5 things that send limits down too 14:15:17 alright 14:15:21 alex_xu: api meeting highlights? 14:15:38 maybe not around 14:15:54 i know gmann_afk is pushing patches to remove more extension code and deprecated api extension policies 14:16:09 https://blueprints.launchpad.net/nova/+spec/api-extensions-policy-removal 14:16:12 https://blueprints.launchpad.net/nova/+spec/api-extensions-merge-queens 14:16:26 gibi: notifications highlights? 14:16:33 yepp 14:16:38 We agreed not to implement obj_make_compatible on versioned notifications payload ovos as we are not supporting backporting such ovos today. As a result the only exiting obj_make_compatible method on payload classes has been deleted. 14:16:54 Also agreed to start a reno listing the already merged versioned notifications in Queens. I will propose t 14:16:57 he patch this week 14:17:09 The work to deduplicate notification samples revealed a need to enhance the FakeDriver used in the functional test to generate better samples. Fortunately mriedem already working on that enhancement for another reson. 14:17:16 #link https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:refactor-notification-samples 14:17:19 #link https://review.openstack.org/#/c/509935/ 14:17:20 patch 509935 - nova - Implement power_off/power_on for the FakeDriver 14:17:26 these all the highlights 14:17:40 thanks 14:18:05 as for cinder, we're waiting on this new microversion https://review.openstack.org/#/c/509005/ but looks like that probably won't be updated until after the summit, 14:18:06 patch 509005 - cinder - Add shared_targets and backend_id to volumes 14:18:25 plus i found a problem in the new attach volume flow proposed in nova such that you can attach the same volume to the same instance w/o any errors 14:18:31 which is definitely a behavior change 14:18:45 we talked about a few options for fixing that last week, 14:19:04 i'm not sure we have a definite agreement yet, probably something we'll discuss at the multiattach session at the summit 14:19:24 we might just end up checking for that scenario using BDMs on the nova side 14:19:57 which is racey since we don't have a unique constraint on the BDMs table 14:20:15 i would like to add ^ but it'd be a potential upgrade issue 14:20:25 #topic stuck reviews 14:20:34 there was nothing on the agenda 14:20:40 anything someone wants to bring up here? 14:20:43 mriedem: FWIW, its because the live-migration attach change in the Cinder API was done wrongly 14:20:59 (well different to the spec) 14:21:11 johnthetubaguy: i thought they were checking on host too, but would have to rehash the details 14:21:27 mriedem: +1 14:21:36 #topic open discussion 14:21:46 nothing on the agenda 14:21:50 so the floor is open 14:21:56 This isn't really stuck yet, but wouldn't mind more opinions: http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2017-11-01.log.html#t2017-11-01T14:25:13 14:22:25 TL;DR: is it okay to have identical or very similar class definitions on either side of the placement API boundary, or should we figure out a common place to house them? 14:22:57 sure, either way 14:23:10 this doesn't lock us into api behavior, 14:23:17 it's all easily changed later 14:23:20 so pick one and go withit 14:23:27 efried: after thinking on this closely, I'd prefer to have a shared file for the RequestGroup object definition, make it plain-old-data and no @classmethod stuff, and put different parse functions in nova/scheduler and nova/api/opensyack/placement 14:23:52 throw it in nova/common/ if you want 14:23:56 nova/common/placement.py 14:24:02 or something, whatever :) 14:24:05 nova/scheduler/placement.py 14:24:16 nova/scheduler/utils.py could have a parse method 14:24:29 any other open discussion? 14:24:31 Rather house it in a placement path, cause if/when we split out placement, I want the common def to go with it. 14:24:40 efried: +1 14:25:04 but not "if/when" - "when" 14:25:06 :) 14:25:12 ++ 14:25:26 either way, this isn't going to be the thing that makes splitting it out complicated 14:25:53 true, but the longer we wait, and the more stuff we add, the worse it will be 14:25:58 ++ 14:26:01 #info reminder that there is no nova meeting next week due to the summit 14:26:26 alright thanks everyone, see some of you next week 14:26:28 #endmeeting