14:00:29 <mriedem> #startmeeting nova 14:00:32 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:36 <openstack> The meeting name has been set to 'nova' 14:00:39 <efried> yeaux 14:00:39 <mriedem> oh hello 14:00:40 <gibi> o/ 14:00:40 <takashin> o/ 14:01:20 <mriedem> i'll wait a minute 14:01:25 <edleafe> \o 14:01:41 <jaypipes> o/ 14:01:45 <tssurya> o/ 14:02:36 <mriedem> alright let's get started 14:02:39 <mriedem> #link agenda https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting 14:02:43 <strigazi> o/ 14:02:45 <mriedem> #topic release news 14:02:50 <mriedem> #link Queens release schedule: https://wiki.openstack.org/wiki/Nova/Queens_Release_Schedule 14:03:00 <mriedem> #info Blueprints: 59 targeted, 48 approved, 2 complete 14:03:14 <mriedem> i'm still working on deferring some targeted blueprints which aren't approved 14:03:42 <mriedem> q-2 is December 7th, so a little over 4 weeks ago 14:03:43 <mriedem> *away 14:03:52 <mriedem> #topic bugs 14:04:00 <mriedem> nothing critical 14:04:03 <mriedem> #info 12 new untriaged bugs (down 6 from last week) 14:04:17 <mriedem> gate status is ok, 14:04:25 <mriedem> we have one known issue, 14:04:44 <mriedem> https://review.openstack.org/#/c/517009/ 14:04:45 <patchbot> patch 517009 - nova - Avoid deleting allocations for instances being built 14:04:57 <mriedem> #link known gate failure https://launchpad.net/bugs/1729371 14:04:59 <openstack> 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 <mriedem> 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 <mriedem> since we shouldn't hit this often 14:06:07 <mriedem> 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 <mriedem> ping me in -nova if you have questions 14:06:37 <mriedem> there is no news for 3rd party ci 14:06:44 <mriedem> #topic reminders 14:06:51 <mriedem> Work on Forum session discussion etherpads and presentations. https://wiki.openstack.org/wiki/Forum/Sydney2017 14:07:05 <mriedem> anyone giving presentations should hopefully have those sorted out by now :) 14:07:24 <mriedem> but for the forum sessions we're still filling in agendas into the etherpads 14:07:45 <mriedem> #topic stable branch status 14:07:49 <mriedem> #link stable/pike: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/pike,n,z 14:07:54 <mriedem> #link Etherpad for bugs tracked for Pike backports: https://etherpad.openstack.org/p/nova-pike-bug-fix-backports 14:08:05 <mriedem> i wanted to point out this series 14:08:12 <mriedem> #help review backports https://review.openstack.org/#/q/topic:bug/1702454+status:open 14:08:26 <mriedem> that's needed to fix a broken API change since newton, 14:08:38 <evrardjp> oh 14:08:44 <mriedem> where we added the ability to specify a host during evacuate 14:08:52 <mriedem> because of the request spec stuff there, that never actually worked 14:08:56 <mriedem> nor in ocata 14:09:09 <mriedem> so i'd like to get that stuff fixed before we actually EOL the newton branch 14:09:31 <mriedem> johnthetubaguy: ^ as stable core 14:09:55 <evrardjp> 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 <mriedem> #link stable/ocata: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/ocata,n,z 14:10:11 <mriedem> #link stable/newton: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/newton,n,z 14:10:22 <mriedem> #info newton 14.0.9 released 14:10:27 <mriedem> so newton was supposed to be eol like 2 weeks ago 14:10:35 <mriedem> but we've had a few high severity fixes holding that up 14:10:42 <mriedem> and tonyb has been kind enough to oblige me 14:10:53 <evrardjp> :) 14:11:03 <mriedem> so newton-eol for nova won't happen until sometime after the summit 14:11:06 <evrardjp> Do we have en ETA? 14:11:10 <evrardjp> ok 14:11:19 <evrardjp> thanks for the info. 14:11:44 <mriedem> evrardjp: if i had to guess, i'd guess final newton release on 11/16 and then EOL the following monday 14:11:51 <mriedem> so 11/20 14:12:05 <mriedem> 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 <mriedem> ok moving on 14:12:27 <mriedem> #topic subteam highlights 14:12:33 <mriedem> there was no cellsv2 meeting last week 14:12:36 <mriedem> *yesterday :) 14:12:45 <mriedem> edleafe: scheduler stuff? 14:12:50 <edleafe> All patch series moving forward. 14:12:50 <edleafe> Lots of bets being made on the race for the next microversion. 14:12:50 <edleafe> Most people getting ready for Sydney (sorry, jaypipes and efried!) 14:12:51 <edleafe> That's all, mate. 14:13:23 <mriedem> speaking of scheduler, let's get this IndexError fix in soonish https://review.openstack.org/#/c/517134/ 14:13:24 <patchbot> patch 517134 - nova - Fix return type in FilterScheduler._legacy_find_hosts 14:13:46 <edleafe> There's also a few limits issues I'm fixing 14:14:00 <mriedem> edleafe: in your alternate hosts series or separate? 14:14:03 <edleafe> Claims expects a dict, and is getting a SchedulerLimits object instead 14:14:26 <edleafe> Yeah - the result of switching to SchedulerLimits in the Selection object 14:14:42 <mriedem> ok yeah, that's because we pass the host_state.limits dict to build_and_run_instance 14:14:47 <mriedem> which goes to the claim 14:14:51 <edleafe> yep 14:14:52 <mriedem> well, today anyway 14:14:59 <edleafe> turned up in some functional tests 14:15:06 <mriedem> plus the other 5 things that send limits down too 14:15:17 <mriedem> alright 14:15:21 <mriedem> alex_xu: api meeting highlights? 14:15:38 <mriedem> maybe not around 14:15:54 <mriedem> i know gmann_afk is pushing patches to remove more extension code and deprecated api extension policies 14:16:09 <mriedem> https://blueprints.launchpad.net/nova/+spec/api-extensions-policy-removal 14:16:12 <mriedem> https://blueprints.launchpad.net/nova/+spec/api-extensions-merge-queens 14:16:26 <mriedem> gibi: notifications highlights? 14:16:33 <gibi> yepp 14:16:38 <gibi> 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 <gibi> Also agreed to start a reno listing the already merged versioned notifications in Queens. I will propose t 14:16:57 <gibi> he patch this week 14:17:09 <gibi> 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 <gibi> #link https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:refactor-notification-samples 14:17:19 <gibi> #link https://review.openstack.org/#/c/509935/ 14:17:20 <patchbot> patch 509935 - nova - Implement power_off/power_on for the FakeDriver 14:17:26 <gibi> these all the highlights 14:17:40 <mriedem> thanks 14:18:05 <mriedem> 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 <patchbot> patch 509005 - cinder - Add shared_targets and backend_id to volumes 14:18:25 <mriedem> 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 <mriedem> which is definitely a behavior change 14:18:45 <mriedem> we talked about a few options for fixing that last week, 14:19:04 <mriedem> 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 <mriedem> we might just end up checking for that scenario using BDMs on the nova side 14:19:57 <mriedem> which is racey since we don't have a unique constraint on the BDMs table 14:20:15 <mriedem> i would like to add ^ but it'd be a potential upgrade issue 14:20:25 <mriedem> #topic stuck reviews 14:20:34 <mriedem> there was nothing on the agenda 14:20:40 <mriedem> anything someone wants to bring up here? 14:20:43 <johnthetubaguy> mriedem: FWIW, its because the live-migration attach change in the Cinder API was done wrongly 14:20:59 <johnthetubaguy> (well different to the spec) 14:21:11 <mriedem> johnthetubaguy: i thought they were checking on host too, but would have to rehash the details 14:21:27 <johnthetubaguy> mriedem: +1 14:21:36 <mriedem> #topic open discussion 14:21:46 <mriedem> nothing on the agenda 14:21:50 <mriedem> so the floor is open 14:21:56 <efried> 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 <efried> 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 <mriedem> sure, either way 14:23:10 <mriedem> this doesn't lock us into api behavior, 14:23:17 <mriedem> it's all easily changed later 14:23:20 <mriedem> so pick one and go withit 14:23:27 <jaypipes> 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 <mriedem> throw it in nova/common/ if you want 14:23:56 <mriedem> nova/common/placement.py 14:24:02 <mriedem> or something, whatever :) 14:24:05 <mriedem> nova/scheduler/placement.py 14:24:16 <mriedem> nova/scheduler/utils.py could have a parse method 14:24:29 <mriedem> any other open discussion? 14:24:31 <efried> 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 <edleafe> efried: +1 14:25:04 <edleafe> but not "if/when" - "when" 14:25:06 <edleafe> :) 14:25:12 <efried> ++ 14:25:26 <mriedem> either way, this isn't going to be the thing that makes splitting it out complicated 14:25:53 <edleafe> true, but the longer we wait, and the more stuff we add, the worse it will be 14:25:58 <efried> ++ 14:26:01 <mriedem> #info reminder that there is no nova meeting next week due to the summit 14:26:26 <mriedem> alright thanks everyone, see some of you next week 14:26:28 <mriedem> #endmeeting