14:00:42 <melwitt> #startmeeting nova
14:00:43 <openstack> Meeting started Thu Jul 26 14:00:42 2018 UTC and is due to finish in 60 minutes.  The chair is melwitt. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:44 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:46 <openstack> The meeting name has been set to 'nova'
14:00:50 <melwitt> hello everybody
14:00:53 <dansmith> o/
14:00:54 <takashin_> o/
14:00:55 <gmann> o/
14:01:05 <mriedem> o/
14:01:12 <melwitt> let's make a start
14:01:20 <melwitt> #topic Release News
14:01:26 <melwitt> #link Rocky release schedule: https://wiki.openstack.org/wiki/Nova/Rocky_Release_Schedule
14:01:35 <melwitt> today is feature freeze r-3 milestone
14:01:39 <gibi> o/
14:01:44 <melwitt> #link https://etherpad.openstack.org/p/nova-rocky-blueprint-status
14:01:52 <melwitt> we've been tracking blueprint status here
14:01:57 * gibi needs to drop off around half past
14:02:21 <melwitt> making pretty good progress on most things, IMHO
14:02:27 <melwitt> #link Rocky review runways: https://etherpad.openstack.org/p/nova-runways-rocky
14:02:34 <melwitt> #link runway #1: Use neutrons new port binding API https://blueprints.launchpad.net/nova/+spec/neutron-new-port-binding-api (mriedem) [END DATE: 2018-07-26] https://review.openstack.org/434870
14:02:38 <edleafe> \o
14:02:41 <melwitt> #link runway #2: NUMA-aware vSwitches https://blueprints.launchpad.net/nova/+spec/numa-aware-vswitches (stephenfin) [END DATE: 2018-07-26] https://review.openstack.org/#/c/564440
14:02:47 <melwitt> #link runway #3: Multiple Fixed-IPs support in network information https://blueprints.launchpad.net/nova/+spec/multiple-fixed-ips-network-information (mgagne) [END DATE: 2018-07-26] https://review.openstack.org/580742
14:03:02 <melwitt> thanks for updating the agenda efried
14:03:55 <melwitt> the reshaper series hasn't made as much progress as we had hoped, so we're looking at either a FFE or it or deciding to defer it
14:04:02 <efried> ō/
14:04:20 <melwitt> thoughts?
14:04:36 <mriedem> defer
14:04:39 <dansmith> thoughts on what, FFE for reshaper?
14:04:45 <mriedem> there is no time
14:04:47 <melwitt> yes
14:04:56 <melwitt> dansmith: yes
14:05:01 <mriedem> as i said in -nova about an hour ago,
14:05:02 <melwitt> or to defer
14:05:04 <dansmith> yeah, seems like it won't ben near enough
14:05:15 <dansmith> I said in -placement yesterday
14:05:24 <mriedem> i think it just means, instead of migrating NRP inventory for libvirt *before* getting to stein, it now means you'll have to do the migration when you get to stein
14:05:41 <mriedem> libvirt + xen
14:05:47 <mriedem> *xenserver
14:05:56 <cdent> I think we should merge the api side, but defer the client side. While it's likely we'll find some changes as a result of the client side work, we've got the broad strokes worked out
14:06:06 <dansmith> it means you'll migrate your inventory in whatever release the reshaper lands in, so "no change" :)
14:06:22 <mriedem> cdent: i don't see much benefit in doing that right now
14:06:42 <cdent> mriedem: the benefit is as I described in openstack-placement: it helps to keep extraction on target
14:06:45 <mriedem> until we've had a lot of review on the client side and are happy with what we have and the api doesn't require any last minute changes
14:06:56 <dansmith> yep
14:07:05 <dansmith> I've got a stack of things in front of me for the day and that's not on it, just FYI
14:07:09 <efried> fwiw with the testing I did yesterday, I'm pretty durn confident that the server side is solid.
14:07:13 <dansmith> with the gate rejecting like 50% of everythin,
14:07:16 <cdent> and also it just makes sure that even if we don't extract, we aren't creating a bunch of placement-side merge conflicts later
14:07:25 <dansmith> there is a long road just to land things that are already approved in the next several days I tink
14:07:57 <cdent> If I were to ask for an FFE for the server-side are there any odds it would be approved?
14:08:11 <cdent> (especially if I said something nice in the justification)
14:08:23 <efried> What's that process? I'm not familiar.
14:08:33 <cdent> (nbd if not)
14:08:38 <efried> Who gets to decide, core vote? PTL?
14:09:17 <mriedem> in the past,
14:09:24 <mriedem> people have submitted requests in the ML,
14:09:37 <mriedem> then we've setup a time in the channel to talk about them so it's open
14:09:47 <mriedem> ultimately PTL is the tie breaker on anything
14:10:01 <mriedem> remember we have 2 weeks to RC1
14:10:12 <dansmith> ...and the gate isn't merging much
14:10:31 <mriedem> and should be spending the majority of our time in those 2 weeks testing and fixing regressions, docs, upgrade automation, release notes, etc
14:11:10 <dansmith> did we lose melwitt ?
14:11:13 <mriedem> so like all good project mgmt things it would be a cost / benefit / risk analysis thing
14:11:27 <gmann> if i remember correctly, it needed at least 2 cores to volunteer for review that BP?
14:11:44 <mriedem> gmann: generally yeah
14:11:45 <melwitt> no, just thinking about how we haven't really had a formal FFE process the past some cycles, at least not that I remember
14:12:11 <mriedem> i know i've made etherpads of FFE requests and we've talked through them in the past
14:12:15 <mriedem> i could probably find the emails in the ML
14:12:22 <dansmith> ...yeah, reasonably formal
14:12:29 <cdent> I guess I/we'll wait and see if jay has an opinion. I'm not hugely concerned, it would just be nice. Jay may care more.
14:12:38 <melwitt> and I agree that it feels like there's not enough time before RC1 to have much in the way of any FFE
14:13:21 <melwitt> okay, then maybe I've dropped the ball on that, so I'm sorry. I didn't notice any announcements about FFEs in recent cycles
14:15:06 <melwitt> cdent: has jay been out this week? I haven't seen his reviews on the reshaper stuff recently
14:15:16 <dansmith> melwitt: he had an eye expode
14:15:18 <dansmith> *explode
14:15:22 <dansmith> goo everywhere
14:15:31 <efried> lame excuse, if you ask me
14:15:38 <melwitt> wow, okay
14:15:39 <dansmith> and like the wus that is he, he says that interferes with reviewing
14:15:43 <cdent> melwitt: yeah, he sent some mail to say that he was going to try to do some reviews but that $work was taking precedence
14:16:03 <mriedem> he will probably take all of this as serious criticism
14:16:13 <dansmith> I hope he does
14:16:14 <mriedem> so remember, obligatory :P
14:16:17 <dansmith> hah
14:16:38 <mriedem> otherwise mnaser will come knocking
14:16:40 * dansmith should :P every one of his sentences via irc client script
14:17:05 <melwitt> okay, I had just been thinking that he's one of the people who knows the nitty gritty on how reshaper needs to work, so his reviews on that are important
14:17:26 <mnaser> >:(
14:17:30 * mnaser lets y'all get back to meeting
14:18:15 <mriedem> btw, there is some FFE stuff in docs here https://docs.openstack.org/nova/queens/contributor/process.html#non-priority-feature-freeze
14:19:02 <melwitt> mriedem: I see
14:19:04 <melwitt> sorry everyone
14:19:11 <cdent> I think it's already pretty clear that at least in the case of reshaper, it is probably better/easier to punt the whole thing unless jay has a strong opinion
14:20:26 <melwitt> yeah, I was thinking that if there aren't major problems we'd have for rocky if we defer it, it'd be best to defer it
14:21:08 <dansmith> we've been sitting here for like 15 minutes, probably need to move on or make a call or something
14:21:26 <melwitt> I think we should just defer it
14:22:36 <gibi> +1
14:23:03 <melwitt> okay, we'll defer reshaper to stein
14:23:10 <melwitt> anything else for release news or runways?
14:23:36 <melwitt> #topic Bugs (stuck/critical)
14:23:49 <melwitt> no critical bugs in the link
14:23:55 <melwitt> #link 49 new untriaged bugs (down 1 since the last meeting): https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New
14:24:13 <melwitt> #link 5 untagged untriaged bugs (up 1 since the last meeting): https://bugs.launchpad.net/nova/+bugs?field.tag=-*&field.status%3Alist=NEW
14:24:14 <melwitt> #link bug triage how-to: https://wiki.openstack.org/wiki/Nova/BugTriage#Tags
14:24:15 <melwitt> #help need help with bug triage
14:24:17 <melwitt> thanks to all who've been helping with triage
14:24:42 <melwitt> we especially need to be looking at these as we get closer to RC1, in 2 weeks
14:24:47 <melwitt> Gate status
14:24:55 <mriedem> and start tagging rocky-rc-potential bugs
14:25:03 <mriedem> i started doing that for i think 2 bugs
14:25:13 <mriedem> probably want to start an etherpad for tracking status on those
14:25:19 <mriedem> i could dig up the example from queens
14:25:24 <gmann> +1
14:25:44 <melwitt> thanks for the suggestion. I can find the queens etherpad I think
14:26:07 <melwitt> #action melwitt to create RC1 bug status tracking etherpad
14:26:30 <melwitt> #link check queue gate status http://status.openstack.org/elastic-recheck/index.html
14:26:45 <melwitt> the gate has been really slow, as we've noticed
14:26:57 <melwitt> I think mostly because of job timeouts at this point?
14:26:59 <mriedem> the gate has sucked
14:27:03 <mriedem> it's lots of things,
14:27:08 <melwitt> mriedem sent a mail to the dev ML about the timeouts
14:27:09 <dansmith> 200 in check and lots of failures,
14:27:11 <mriedem> i've been categorizing stuff the last 2 days
14:27:14 <dansmith> hours before things start running
14:27:18 <mriedem> http://status.openstack.org/elastic-recheck/
14:27:29 <mriedem> we aren't even at 50% categorization on failures http://status.openstack.org/elastic-recheck/data/integrated_gate.html
14:27:31 <dansmith> even stuff +2d right now will likely take days
14:27:45 <mriedem> this is a major one http://status.openstack.org/elastic-recheck/index.html#1775947
14:27:46 <mriedem> and it's nova
14:28:05 <mriedem> i personally think we should probably comment out the part of the test that fails until we have a better idea of how to debug it
14:28:29 <mriedem> this is the slow tempest one http://status.openstack.org/elastic-recheck/index.html#1783405
14:28:51 <mriedem> gmann has an ethercalc for tests that are candidates to be marked slow, which includes compute API tests
14:29:07 <gmann> #link https://ethercalc.openstack.org/dorupfz6s9qt
14:29:11 <mriedem> those are the 2 big ones on my radar
14:29:13 <melwitt> #link intermittent failing nova test in tempest http://status.openstack.org/elastic-recheck/index.html#1775947
14:29:28 <melwitt> #link slow tests randomly timing out jobs http://status.openstack.org/elastic-recheck/index.html#1783405
14:29:31 <melwitt> thanks mriedem
14:30:22 <melwitt> 3rd party CI
14:30:26 <melwitt> #link 3rd party CI status http://ci-watch.tintri.com/project?project=nova&time=7+days
14:30:29 * gibi has to drop from the meeting now. left two notes on the agenda about the notification subteam.
14:30:42 <melwitt> I noticed that virtuozzo CI is back and passing
14:30:43 <gmann> we talked on marking slow test in today QA office hour and we can mark them slow based on need and exclude them from tempest-full to unblock the gate. later we can check if we need to refactor such test
14:31:18 <melwitt> gmann: I was wondering, should we -W the change that's up to add the new job that includes slow tests then?
14:31:49 <gmann> melwitt: yeah, that's better i think. no point to get those voting at this stage
14:31:58 <melwitt> this one https://review.openstack.org/567697
14:32:02 <melwitt> okay
14:32:09 <mriedem> well,
14:32:18 <mriedem> isn't the point of the slow job to actually run the slow tests and only the slow tests?
14:32:22 <mriedem> the tests themselves aren't timing out,
14:32:26 <mriedem> it's the overall tempest run itself
14:32:34 <mriedem> b/c there are too many tests and too many of those that are slow
14:32:54 <melwitt> that job is all scenario tests including slow
14:32:57 <mriedem> if we mark stuff slow but don't run them in a voting job, we'll have no idea when we regress something
14:33:09 <mriedem> hmm, not sure why we'd do that
14:33:33 <mriedem> but i know gmann posted lots of words in the ML about it and i didn't grok it all and don't want to talk about it here
14:33:40 <gmann> mriedem: as of now it run all scenario it was n-v till now in temepest and which was goind good till now
14:34:04 <gmann> it create issue mainly running scenario tests with all API tests in parallel
14:34:48 <melwitt> okay, so what we want to do is look into a job that runs only 'slow' tests
14:34:53 <melwitt> sounds like
14:35:13 <melwitt> going to try to move on, anything else for bugs or gate?
14:35:23 <gmann> mriedem: you need to -W this till Rocky (i cannot as not author) - #link https://review.openstack.org/#/c/567697/
14:35:38 <mriedem> gmann: i commented in there,
14:35:42 <gmann> k
14:35:42 <mriedem> we can talk about it in the review or after the meeting
14:36:14 <melwitt> #topic Reminders
14:36:20 <melwitt> #link Rocky Subteam Patches n Bugs: https://etherpad.openstack.org/p/rocky-nova-priorities-tracking
14:36:24 <melwitt> #link Stein PTG planning: https://etherpad.openstack.org/p/nova-ptg-stein
14:36:45 <melwitt> I'm going to make an etherpad and ML post for a rocky retrospective for the PTG too
14:37:07 <melwitt> rc1 is in two weeks August 9
14:37:17 <melwitt> anyone have any other reminders?
14:37:42 <melwitt> #topic Stable branch status
14:37:47 <melwitt> #link stable/queens: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/queens,n,z
14:38:02 <melwitt> #link stable/pike: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/pike,n,z
14:38:07 <melwitt> #link stable/ocata: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/ocata,n,z
14:38:51 <melwitt> I was thinking we should do releases for stable for the last milestone
14:39:27 <mriedem> agree
14:39:33 <mriedem> but,
14:39:38 <mriedem> that could be queued up next week,
14:39:48 <mriedem> so stable reviews tomorrow while we're just rechecking rc3 stuff
14:39:52 <mriedem> *r-3
14:40:09 <melwitt> okay, that sounds good
14:40:43 <melwitt> anything else for stable branch status?
14:40:59 <melwitt> #topic Subteam Highlights
14:41:09 <melwitt> we skipped the cells meeting yesterday because crunch time
14:41:37 <melwitt> dansmith: anything you'd like to add? I know we are almost done with the queued_for_delete part of handling a down cell, which I'll take a look at after this
14:41:54 <dansmith> nope, have been looking at other stuff all week
14:41:55 <melwitt> the rest of it is deferred to stein
14:41:59 <efried> I think I sent that to the gate this morning.
14:42:09 <mriedem> it's already approved
14:42:10 <mriedem> yeah
14:42:11 <mriedem> https://review.openstack.org/#/c/566813/
14:42:13 <melwitt> oh, okay. great
14:42:56 <melwitt> efried has included a link to scheduler subteam minutes in the agenda
14:43:01 <melwitt> #link scheduler subteam minutes http://eavesdrop.openstack.org/meetings/nova_scheduler/2018/nova_scheduler.2018-07-23-14.00.html
14:43:02 <melwitt> Notification (gibi) [07.26]
14:43:09 <efried> - Much time was spent talking about the reshaper series, of course.
14:43:10 <efried> The db side is merged.
14:43:10 <efried> #link Currently the reshaper series starts with the microversion patch https://review.openstack.org/#/c/576927/
14:43:10 <efried> We agreed to put a procedural hold on it until the client side (the subsequent 7 patches) stabilizes.
14:43:10 <efried> A bug was found on the db side
14:43:11 <efried> #link IndexError when clearing a provider's inventories: https://bugs.launchpad.net/nova/+bug/1783130
14:43:11 <openstack> Launchpad bug 1783130 in OpenStack Compute (nova) "placement reshaper doesn't clear all inventories for a resource provider" [Medium,In progress] - Assigned to Eric Fried (efried)
14:43:11 <efried> ...which now has a fix proposed in that series:
14:43:11 <efried> #link fix for bug 1783130 https://review.openstack.org/#/c/585033/
14:43:12 <efried> We agreed to "just fix" https://bugs.launchpad.net/nova/+bug/1782340 rather than require a microversion, which was done via https://review.openstack.org/#/c/583907/ (now merged)
14:43:12 <efried> Between those two bugfixes, the series passes tests at this point.
14:43:12 <efried> - Work has started on integrating consumer gen microversion into the client side
14:43:12 <openstack> Launchpad bug 1782340 in OpenStack Compute (nova) "allocation schema does not set additionalProperties False in all the right places" [Medium,Fix released] - Assigned to Chris Dent (cdent)
14:43:13 <efried> #link consumer generation handling (gibi): https://review.openstack.org/#/c/583667/
14:43:13 <efried> ...but other things (nrp affordance for initial & migration scheduling, etc.) have not been started.
14:43:14 <efried> - We brought up the os-resource-classes efforts, of which there are two proposals, one rich, one lean:
14:43:41 <efried> Yeesh, I just got a spambot notice for that.
14:44:48 <LuK1337153> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
14:44:48 <LuK1337153> or maybe this blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
14:44:48 <LuK1337153> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
14:44:55 <efried> oy vay
14:44:59 <melwitt> efried: was that all of the update?
14:45:13 <efried> melwitt: I hope so, not sure what y'all saw.
14:45:20 <efried> Did you see END at the end?
14:45:28 <melwitt> oh, last thing was "We brought up the os-resource-classes efforts, of which there are two proposals, one rich, one lean:"
14:45:29 <melwitt> no
14:45:37 <efried> okay, here's the rest:
14:45:46 <efried> #link os-resource-classes proposal from Jay: https://github.com/jaypipes/os-resource-classes
14:45:51 <efried> #link os-resource-classes proposal from Chris: https://github.com/cdent/os-resource-classes
14:45:56 <efried> Agreed to not worry too much about those until the PTG, so they're on the etherpad.
14:46:02 <efried> - #link Add nova-manage placement sync_aggregates https://review.openstack.org/#/c/575912/
14:46:06 <efried> ...was discussed, agreed to do it the way it is now (which talks raw placement URIs) and defer refactoring to use report client helpers at a later time. It has since been merged.
14:46:08 <efried> END
14:46:25 <melwitt> cool, thanks
14:46:46 <melwitt> we have a status mail for the notifications subteam from gibi on the agenda
14:46:50 <efried> Not sure if my indignance at being spambotted is justified.
14:47:05 <melwitt> #link notification subteam status http://lists.openstack.org/pipermail/openstack-dev/2018-July/132410.html
14:47:15 <melwitt> and they didn't have a meeting this week
14:47:30 <melwitt> API subteam has an update link from gmann
14:47:49 <melwitt> #link Latest API updates http://lists.openstack.org/pipermail/openstack-dev/2018-July/132461.html
14:47:56 <melwitt> anything else for subteams?
14:48:13 <melwitt> #topic Stuck Reviews
14:48:25 <melwitt> nothing on the agenda for stuck reviews. anyone in the room have anything for stuck reviews?
14:48:51 <bauzas> looks not :)
14:48:53 <melwitt> #topic Open discussion
14:49:07 <melwitt> nothing on the agenda for open discussion. anyone in the room have anything for open discussion?
14:49:42 <melwitt> okay, thanks everyone
14:49:44 <melwitt> #endmeeting