14:01:56 <efried> #startmeeting nova
14:01:57 <openstack> Meeting started Thu Aug  8 14:01:56 2019 UTC and is due to finish in 60 minutes.  The chair is efried. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:58 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:02:00 <openstack> The meeting name has been set to 'nova'
14:02:20 <takashin> o/
14:02:22 <gmann> o/
14:02:31 * gmann in TC meeting also in parallel
14:02:35 <cdent> o/
14:02:45 <dansmith> o/
14:03:41 <gibi> o/
14:05:11 <efried> #link agenda https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting
14:05:15 <efried> (updated just now)
14:05:33 <efried> #topic Last meeting
14:05:33 <efried> #link Minutes from last meeting: http://eavesdrop.openstack.org/meetings/nova/2019/nova.2019-08-01-21.00.html
14:06:08 <efried> actions from last time will come around again in open discussion
14:06:16 <efried> #topic Release News
14:06:24 <efried> We're in code mode now.
14:06:45 <efried> Feature freeze in ~5 weeks, Sep 12
14:07:12 <efried> #topic Bugs (stuck/critical)
14:07:12 <efried> No Critical bugs
14:07:12 <efried> #link 67 new untriaged bugs (-0 since the last meeting): https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New
14:07:12 <efried> #link 1 untagged untriaged bugs (-1 since the last meeting): https://bugs.launchpad.net/nova/+bugs?field.tag=-*&field.status%3Alist=NEW
14:07:20 <efried> any bug news?
14:08:07 <efried> #topic Gate status
14:08:07 <efried> #link check queue gate status http://status.openstack.org/elastic-recheck/index.html
14:08:07 <efried> #link 3rd party CI status (seems to be back in action) http://ciwatch.mmedvede.net/project?project=nova
14:08:43 <efried> we seem to be hitting 700-ish in-use nodes in the CI http://grafana.openstack.org/d/rZtIH5Imz/nodepool?orgId=1
14:08:48 <efried> which is a big bump
14:09:04 <efried> yet anecdotally, build times don't seem to have gone down a whole lot.
14:09:18 <efried> any comments there?
14:09:38 <efried> #topic Reminders
14:09:38 <efried> Anything?
14:09:56 <efried> #topic Stable branch status
14:09:56 <efried> #link stable/stein: https://review.openstack.org/#/q/status:open+(project:openstack/os-vif+OR+project:openstack/python-novaclient+OR+project:openstack/nova)+branch:stable/stein
14:09:56 <efried> #link stable/rocky: https://review.openstack.org/#/q/status:open+(project:openstack/os-vif+OR+project:openstack/python-novaclient+OR+project:openstack/nova)+branch:stable/rocky
14:09:56 <efried> #link stable/queens: https://review.openstack.org/#/q/status:open+(project:openstack/os-vif+OR+project:openstack/python-novaclient+OR+project:openstack/nova)+branch:stable/queens
14:10:05 <efried> I think mriedem is gearing up for a rocky release
14:10:08 <mriedem> yes,
14:10:12 <mriedem> cve fixes https://review.opendev.org/#/q/I5e0a43ec59341c9ac62f89105ddf82c4a014df81
14:10:14 <efried> #help stables review rocky patches please
14:10:50 <efried> anything else stable mriedem?
14:10:53 <mriedem> no
14:11:00 <efried> #topic Sub/related team Highlights
14:11:00 <efried> Placement (cdent)
14:11:00 <efried> #link latest pupdate http://lists.openstack.org/pipermail/openstack-discuss/2019-August/008192.html
14:11:07 <cdent> oh hi
14:11:32 <efried> cdent has been diligently chipping away at performance
14:11:34 <cdent> lots of performance updates that have proven quite useful. I'm going to write up a thing about the general classes of changes that were made so that we can try to transfer some of them over to nova
14:11:41 <efried> ++
14:12:07 <cdent> if I continue to have the time and space to do so, I'm just gonna carry on with the same analysis in nova-land
14:12:07 <efried> that it?
14:12:13 <cdent> one thing that may be a concern:
14:12:58 <cdent> tssurya: not sure if you are here, but I'll speak your name in vain. They are working on implementing consumer types in placement (which is of value to nova quotas) and progress is relatively slow (compared to other features in placement this cycle)
14:13:25 <cdent> for the sake of nova we may want to see about helping out with that, depending on what tssurya has to say
14:13:33 <cdent> (that's all)
14:14:00 <efried> who on the nova side is counting on consumer types? melwitt?
14:14:02 <tssurya> cdent: I wasn't aware it was a priority honestly
14:14:05 <tssurya> on the nova side
14:14:16 <cdent> tssurya: I don't know if it is or not, which is why I bring it up
14:14:24 <cdent> if it's not, then no big deal
14:14:37 <cdent> if it is, then we can perhaps make some adjustments
14:14:50 <mriedem> i should probably read that spec,
14:14:54 <tssurya> the slow progress is truly my fault, apologies
14:15:09 <mriedem> since knowing the type of consumer for allocations could be useful for when we're deleting a compute service and hit conflicts, or the audit placement cli
14:15:20 <cdent> tssurya: we've all got many things on the plate, don't worry
14:15:23 <mriedem> but none of those are priorities as far as i know
14:16:19 <efried> mriedem: you appear to have at least glanced at the spec on June 27th
14:16:21 <cdent> at least of the people here, it sounds like no one is clamouring, but not everyone is here
14:17:14 <efried> Yeah, I can't quite tell from the
14:17:15 <efried> #link consumer types spec (review) https://review.opendev.org/#/c/654799/
14:17:15 <efried> who/what the major motivators were
14:17:32 <efried> but melwitt was at least involved, so probably need to fup with her
14:17:41 <efried> cdent: your action ^ ?
14:17:56 <cdent> sure, I'll check in
14:18:05 <efried> #action cdent to track down why we care about consumer types, and how motivated we should be to close it in Train
14:18:10 <efried> thanks
14:18:19 <efried> moving on
14:18:32 <efried> #topic Stuck Reviews
14:18:33 <efried> any?
14:19:09 <efried> #topic Review status page
14:19:10 <efried> #link http://status.openstack.org/reviews/#nova
14:19:10 <efried> Count: 459 (-2); Top score: 1373 (+21)
14:19:10 <efried> (FWIW, one week == 21 points)
14:19:10 <efried> #help Pick a patch near the top, shepherd it to closure
14:19:28 <efried> #topic Open discussion
14:19:28 <efried> Train Spec Freeze Exception Process
14:19:37 <efried> Last week we decided to dump all the decisions on dansmith
14:19:38 <gmann> efried: you missed API :)
14:19:46 <efried> Ugh, sorry gmann
14:19:54 <efried> #topic Sub/related team Highlights
14:19:59 <efried> API (gmann)
14:19:59 <efried> This week updates: http://lists.openstack.org/pipermail/openstack-discuss/2019-August/008358.html
14:19:59 <efried> gmann is working on 'Default policy refresh' and first API policies (os-services) series of changes is up for early feedback and direction.
14:19:59 <efried> This patch and all base patches: https://review.opendev.org/#/c/648480/7
14:20:01 <dansmith> #undo is a thing
14:20:18 <gmann> mainly on thing about early feedback
14:20:24 <gmann> regarding the last one "policy default refresh" initial series, i will catch melwitt and johnthetubaguy after meeting to discuss if this direction is good for them. and also will try to prepare an etherpad to write down the  each changes motive to make it easy for review
14:20:47 <gmann> i am looking for early feedback on this and its base patches https://review.opendev.org/#/c/648480/
14:20:54 <efried> "review guide on ML" has been helpful for things.
14:21:05 <gmann> and same line we can work on other policy also
14:21:13 * efried still has mriedem's cross-cell resize review guide in the queue....
14:21:13 <gmann> efried: sure. i can add that on ML
14:21:43 <gmann> that's all on API.
14:21:56 <efried> thanks gmann
14:22:14 <efried> #topic Open discussion
14:22:14 <efried> Train Spec Freeze Exception Process
14:22:21 <efried> Last week we decided to dump all the decisions on dansmith
14:22:51 <efried> ...who has commented on both of the specs:
14:22:51 <efried> #link Use PCPU and VCPU in One Instance: https://review.opendev.org/#/c/668656/
14:22:51 <efried> #link Nova Part of Image Encryption: https://review.opendev.org/#/c/608696
14:23:13 <efried> dansmith: are we saying definitively no at this point?
14:23:27 <dansmith> I never signed up to make the final call,
14:23:29 <dansmith> but tbh,
14:23:31 <mriedem> i say defer
14:23:31 <efried> Heh
14:23:37 <efried> no, we signed you up in absentia
14:23:40 <mriedem> if these aren't clear at this point in train, defer
14:23:40 <dansmith> it seems like there is little support for either being an exception
14:23:43 <mriedem> they aren't exception worthy
14:24:11 <efried> Okay.
14:24:27 <mriedem> being rushed for an exception makes one feel like they need to just approve to make people happy and keep the wheels grinding
14:24:57 <efried> I would like to be able to encourage the authors to continue working on the specs, in backlog-land, so they can land early in U.
14:25:06 <mriedem> yeah i think that's fine,
14:25:13 <efried> I haven't been deep in the technical details, but they seemed close to me.
14:25:15 <mriedem> knowing that to go from backlog -> U is still not a trivial re-approval
14:25:27 <dansmith> so, on that,
14:25:40 <dansmith> why don't we just propose them against U, and even potentially approve them at some point?
14:25:48 <dansmith> going into the backlog and then needing a re-review just seems pointless to me
14:26:01 <mriedem> if the U stuff is populated that's also fine
14:26:08 <efried> wfm. As soon as we have a name, I'll (ask someone to) populate the tree and we can do that.
14:26:11 <mriedem> backlog was historically more for an idea or problem w/o a solution
14:26:16 <dansmith> other than to serve as making it look like we've handed them half a bone, to make ourselves and them feel better
14:26:22 <mriedem> takashin has done it in the past
14:26:27 <mriedem> populating nova-specs with the next series
14:26:29 <efried> yuh
14:26:45 <efried> okay, moving on.
14:26:49 <mriedem> aciton?
14:26:52 <mriedem> *action even
14:27:11 <efried> #action takashin to populate nova-specs with U as soon as U has a name
14:27:25 <takashin> okay
14:27:36 <efried> #action Luzi and huaqiang to move their respective specs to U
14:28:10 <efried> Thanks takashin
14:28:14 <efried> (mriedem):
14:28:14 <efried> #link python-novaclient blueprint to add --migration-type and --source-compute filters to "nova migration-list": https://blueprints.launchpad.net/python-novaclient/+spec/more-migration-list-filters
14:28:50 <efried> mriedem is requesting approval for specless blueprint ^
14:28:59 <efried> what say you, all?
14:29:13 <mriedem> i've already got code up, just waiting to write tests,
14:29:21 <mriedem> this isn't dependent on microversion, it's legacy v2.0 stuff,
14:29:29 <mriedem> and it's novaclient, so not really a spec freeze exception kind of thing
14:29:41 <dansmith> heh
14:29:49 <dansmith> widening the gap with OSC, I see!
14:29:52 <mriedem> also, osc doesn't have any migration resource stuff
14:29:54 <efried> was about to say
14:29:58 <mriedem> i would have done osc
14:29:59 <mriedem> except ^
14:30:05 <efried> :(
14:30:07 <gibi> why not both? ;)
14:30:07 <mriedem> and when osc gains migration stuff, it would likely use this
14:30:09 <mriedem> so there
14:30:24 * mriedem checks how many knives he has available
14:30:40 <mriedem> i guess just the one will do
14:30:54 <gibi> works for me
14:30:59 <dansmith> dude, don't stab me with a knife bloodied by someone else
14:31:04 <mriedem> if someone else from the nova team wants to help out with osc gaps i'll be happy to let you know what needs doing
14:31:05 <dansmith> think of the health risks
14:31:12 <mriedem> dansmith: sorry
14:31:52 * cdent must go, bbs
14:32:20 <efried> okay, I'll approve with notes after the meeting.
14:32:25 <efried> anything else?
14:32:50 <efried> Thanks all
14:32:50 <efried> o/
14:32:50 <efried> #endmeeting