21:00:06 <melwitt> #startmeeting nova 21:00:07 <openstack> Meeting started Thu Nov 8 21:00:06 2018 UTC and is due to finish in 60 minutes. The chair is melwitt. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:00:08 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:00:10 <openstack> The meeting name has been set to 'nova' 21:00:19 <mriedem> o/ 21:00:21 <takashin> o/ 21:00:29 <melwitt> howdy everyone, welcome to the nova meeting 21:00:38 <dansmith> ./ 21:00:45 <melwitt> lettuce start 21:00:51 <melwitt> #topic Release News 21:01:03 <melwitt> #link Stein release schedule: https://wiki.openstack.org/wiki/Nova/Stein_Release_Schedule 21:01:12 <melwitt> the summit is next week, tue-thu 21:01:28 <melwitt> next milestone after that s-2 is jan 10 next year, that will also be spec freeze 21:01:39 <melwitt> #link Stein runway etherpad: https://etherpad.openstack.org/p/nova-runways-stein 21:02:01 <melwitt> some runways have not gotten much attention, probably as folks are trying to prepare for summit 21:02:11 <melwitt> #link runway #1: https://blueprints.launchpad.net/nova/+spec/reshape-provider-tree (bauzas/naichuan) [END: 2018-11-08] starts here https://review.openstack.org/#/c/599208/ 21:02:19 <melwitt> #link runway #2: https://blueprints.launchpad.net/nova/+spec/use-nested-allocation-candidates (gibi) [END 2018-11-08] https://review.openstack.org/567268 21:02:38 <melwitt> this one, I'm not sure the status, need to ask gibi ^ 21:02:45 <melwitt> #link runway #3: https://blueprints.launchpad.net/nova/+spec/initial-allocation-ratios (yikun) [END 2018-11-09] starts here https://review.openstack.org/602803 21:03:09 <melwitt> these are all ending soon, so we'll put new blueprints into runways next monday 21:03:22 <melwitt> I was thinking because of summit week, we'll make the end dates 3 weeks from the start instead of 2 21:03:30 <mriedem> i was going to ask about that, and agree 21:03:38 <mriedem> the initial allocs ratio ones didn't seem to get any reviews 21:03:42 <mriedem> or reshape 21:03:46 <melwitt> yeah, I know :( 21:03:54 <melwitt> I'll put those back in the queue 21:04:01 <dansmith> or 21:04:06 <dansmith> just leave them in there for a bonus third week 21:04:12 <melwitt> the past two weeks have been too hectic I think 21:04:18 <melwitt> yeah, that's another option 21:04:41 <efried> o/ 21:04:45 <mriedem> they probably won't get reviewed next week either 21:05:04 <melwitt> yeah, that was my concern on the bonus week. they'd need a bonus two weeks at least 21:05:28 <mriedem> there are 2 single patch bps queued up, 21:05:33 <mriedem> which i don't think should take the full 3 weeks, 21:05:34 <dansmith> presumably that applies to anything you put or leave in there 21:05:38 <mriedem> so i'd just rotate the ones we have after the summit 21:05:41 <dansmith> hence it not seeming to matter 21:06:17 <mriedem> sounds like we need a good ol fashioned HACKATHON 21:06:26 <melwitt> heh 21:07:21 <melwitt> yeah, so I guess let's just rotate in the new ones and put the other two in the queue right behind and that way they all go back into runways in the next few weeks? 21:08:17 <melwitt> ok, I guess I'll do that and if someone complains, we can reassess 21:08:28 <melwitt> anything else for release news or runways before we move on? 21:08:46 <melwitt> #topic Bugs (stuck/critical) 21:08:57 <melwitt> no critical bugs in the link 21:09:05 <melwitt> #link 59 new untriaged bugs (up 8 since the last meeting): https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New 21:09:31 <melwitt> falling behind on triage as summit approaches, not unexpected 21:09:33 <melwitt> #link 7 untagged untriaged bugs (down 2 since the last meeting): https://bugs.launchpad.net/nova/+bugs?field.tag=-*&field.status%3Alist=NEW 21:09:44 <melwitt> doing well on bug tagging, thanks to the bug taggers 21:09:52 <melwitt> #link bug triage how-to: https://wiki.openstack.org/wiki/Nova/BugTriage#Tags 21:10:00 <melwitt> #help need help with bug triage 21:10:13 <melwitt> periodically take a look at tags you know and help triage if you can 21:10:29 <melwitt> Gate status 21:10:30 <melwitt> #link check queue gate status http://status.openstack.org/elastic-recheck/index.html 21:10:37 <melwitt> I don't know of any major issues 21:10:42 <melwitt> 3rd party CI 21:10:48 <melwitt> #link 3rd party CI status http://ci-watch.tintri.com/project?project=nova&time=7+days 21:11:20 <melwitt> anything else for bugs or gate status or third party CI? 21:11:38 <melwitt> ok, moving on 21:11:40 <melwitt> #topic Reminders 21:11:49 <melwitt> #link Stein Subteam Patches n Bugs: https://etherpad.openstack.org/p/stein-nova-subteam-tracking 21:11:54 <melwitt> #link Create etherpads for Forum sessions: https://wiki.openstack.org/wiki/Forum/Berlin2018 21:12:27 <melwitt> I think all our sessions have etherpads by now, I will double check 21:12:35 <melwitt> #link Add your name to cross-project forum sessions if you can attend: https://etherpad.openstack.org/p/nova-forum-stein 21:12:57 <melwitt> we made a list of forum sessions and presentations of interest 21:13:12 <melwitt> please add your name to any cross project sessions you'll be able to attend 21:13:31 <melwitt> that way we can ask you what the highlights of the session were 21:14:00 <melwitt> I think that's all I have for reminders. anyone have any other reminders to add? 21:14:29 <melwitt> #topic Stable branch status 21:14:36 <melwitt> #link stable/rocky: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/rocky,n,z 21:14:42 <melwitt> #link Released rocky 18.0.3 on Nov 5: https://review.openstack.org/614575 21:14:49 <melwitt> #link stable/queens: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/queens,n,z 21:14:54 <melwitt> #link stable/pike: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/pike,n,z 21:15:05 <melwitt> I wanted to ask the group, should we release queens and pike too while we're at it? 21:15:51 <melwitt> I can check if there are a lot of fixes since last release. I expect there will be 21:16:21 <mriedem> haven't looked, 21:16:30 <mriedem> rocky was the big one b/c of several upgrade-related issues/regressions 21:16:40 <mriedem> so queens/pike is less critical right now 21:17:02 <mriedem> i'd say, 21:17:17 <mriedem> we do a stable review push after the summit and try to do a release around dec 21:17:28 <melwitt> I like that idea 21:17:52 <melwitt> ok 21:18:32 <melwitt> anything else for stable branch status? 21:18:50 <melwitt> #topic Subteam Highlights 21:18:58 <melwitt> scheduler, efried? 21:19:09 <efried> I had DST fail, cdent covered. 21:19:14 <efried> http://eavesdrop.openstack.org/meetings/nova_scheduler/2018/nova_scheduler.2018-11-05-14.00.log.html 21:19:35 <efried> Two main topics seem to have been 1) performance improvements, reduction in placement calls; 2) alembic. 21:20:39 <melwitt> yeah, there's an ML thread on that: http://lists.openstack.org/pipermail/openstack-dev/2018-November/136251.html 21:20:47 <melwitt> (for meeting minute readers) 21:21:00 <melwitt> thread on the perf issue 21:21:37 <efried> The PoC patch has been supplanted by some real code, series starting at https://review.openstack.org/#/c/615606/ bottom two of which have merged. 21:22:19 <efried> I'm still working through tests for some of the rest. But if you look at the placement logs after the "Reduce calls from _ensure" patch, you can see it go from ~650K to ~500K 21:22:34 <efried> which is pretty much what we were going for. 21:22:53 <efried> We don't really have a CI job that'll test it in steady state, because our CI jobs do stuff. 21:23:05 <efried> I'll ask CERN to have a look at that hopefully. 21:23:28 <melwitt> yeah, good idea 21:25:03 <melwitt> efried: anything else? 21:25:14 <efried> nope 21:25:26 <melwitt> ok, thanks 21:25:44 <melwitt> no notes on the agenda for the api subteam 21:25:52 <melwitt> #topic Stuck Reviews 21:26:05 <melwitt> no items in the agenda. anyone have something for stuck reviews in the room? 21:26:20 <melwitt> I assume that's no as usual 21:26:27 <melwitt> #topic Open discussion 21:26:38 <melwitt> two items from me 21:26:42 <melwitt> (melwitt): Nova meeting scheduled for 2018-11-22 at 2100 UTC falls on US holiday of Thanksgiving. Question: should we cancel this one since it's during the US time zone and we're unlikely to find anyone to run it? 21:26:56 <mriedem> yes 21:27:31 <melwitt> any objections from anyone? 21:27:50 <melwitt> otherwise I'll send a note to the ML that we won't have meeting next week or week after 21:28:20 <melwitt> next, just a FYI that I'll be on PTO the 2 weeks following summit while I'm in europe 21:28:33 <melwitt> ok, next item on the agenda 21:28:46 <melwitt> (sean-k-mooney): sriov live migration blueprint and spec ready for review https://blueprints.launchpad.net/nova/+spec/libvirt-neutron-sriov-livemigration https://review.openstack.org/#/c/605116/ 21:29:21 <melwitt> heads up that sean has updated the spec to address feedback and is ready for more reviews 21:29:34 <melwitt> one more item in the agenda 21:29:45 <melwitt> (jackding): Blueprint for review (do we need a spec?): Flavor extra spec and image properties validation https://blueprints.launchpad.net/nova/+spec/flavor-extra-spec-image-property-validation 21:30:18 <mriedem> that's an api change, so yeah i think it warrants a spec to at least list the things that will be validated and how 21:30:26 <mriedem> since i doubt we're going to cover everything out there 21:30:26 <jackding> do we need a spec for this one? no API changes but have user interaction if validation fails 21:30:35 <mriedem> it's not a microversion, 21:30:40 <mriedem> but it's definitely a change in the api 21:31:26 <melwitt> L923 from ptg discussions, for those needing a memory refresh https://etherpad.openstack.org/p/nova-ptg-stein 21:32:29 <melwitt> so, is this turning a ERROR instance situation into a synchronous user error from the api? if so, I didn't think that would be considered an api change but more akin to changing a 500 to a non-500 21:33:20 <jackding> yes I think so 21:33:30 <mriedem> how/where this fits into things in the api, which extra specs / image properties are validated and which aren't, what to do with out of tree stuff, etc, i think is enough content to warrant a spec 21:33:45 <melwitt> that's fair 21:34:02 <edleafe> I think definitely a spec. With more information, we can figure out if it needs a microversion 21:34:02 <melwitt> I was hyperfocused on the "api change" characterization 21:34:15 <jackding> sure 21:34:19 <mriedem> agree with ed, 21:34:34 <mriedem> i just don't want to have jackding write a big code series and we get halfway and say, "whoa wtf" 21:34:34 <edleafe> The 500 exception is because no client should ever have code to handle a 500 21:35:16 <mriedem> the user doesn't get a 500 today, but yeah - they get a 202 and then an instance in ERROR state later 21:35:21 <melwitt> well, what I meant by that is, if we're changing behavior from an instance falling into ERROR state and replacing it with a fail fast api error to the user, that's not microversion-worthy 21:35:48 <melwitt> but I'm not a api expert 21:36:38 <melwitt> either way, I agree the amount of content needed to capture the change warrants the spec. and agree I want to catch potential issues early in the spec before jackding does and does a lot of work 21:36:39 <jackding> I agree to have a spec to have this discussion going 21:36:55 <melwitt> *goes and does 21:37:36 <melwitt> ok, cool jackding. you can ping us when you've uploaded the spec 21:37:44 <jackding> ok thanks 21:38:02 <melwitt> anyone have anything else for open discussion before we wrap up? 21:38:51 <melwitt> ok, I guess that's it. happy travels to those going to the summit next week, and seeya there 21:38:56 <melwitt> #endmeeting