21:00:08 <melwitt> #startmeeting nova
21:00:09 <openstack> Meeting started Thu Oct 25 21:00:08 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:10 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:12 <openstack> The meeting name has been set to 'nova'
21:00:15 <melwitt> hi everyone, welcome
21:00:21 <takashin> o/
21:01:01 <mriedem> o/
21:01:42 <edleafe> \o
21:01:51 <melwitt> let's make a start
21:01:59 <melwitt> #topic Release News
21:02:05 <melwitt> #link Stein release schedule: https://wiki.openstack.org/wiki/Nova/Stein_Release_Schedule
21:02:08 <efried> o/
21:02:23 <melwitt> today is milestone 1, so we'll be releasing the first nova beta
21:02:34 <melwitt> #info Today is s-1 and we'll be proposing releases for master and stable branches today. os-traits and python-novaclient have already been released this week. os-vif release has been proposed earlier this week.
21:03:02 <melwitt> stable branches don't have to be today, depending on whether we'll want to land specific things before proposing the release
21:03:12 <melwitt> #link Stein runway etherpad: https://etherpad.openstack.org/p/nova-runways-stein
21:03:18 <melwitt> #link runway #1: https://blueprints.launchpad.net/nova/+spec/reshape-provider-tree (bauzas/naichuan) [END: 2018-11-08] https://review.openstack.org/599208 and https://review.openstack.org/#/c/521041
21:03:29 <melwitt> only have one runway occupied at the moment
21:03:58 <efried> eek, /me should really be paying attention to that. /me curses $work
21:04:11 <efried> btw
21:04:21 <efried> that shouldn't be marked against bp reshape-provider-tree
21:04:36 <melwitt> gibi's nested-resource-allocations recently left a runway but review is still needed, so let's keep paying attention to that. and really we should just put it back in the queue since nothing else is in the queue
21:04:37 <efried> I expressed why in one of the reviews.
21:04:48 <melwitt> oh, hm
21:05:10 <efried> We should totally still review it
21:05:10 <melwitt> where should it go then? is it part of the catch-all for NRP?
21:05:17 <efried> It's a vgpu thing.
21:05:33 <efried> It should be in the same bp as the rest of the xen vgpu stuff.
21:05:45 <melwitt> ok, I'll take a look
21:05:45 <mriedem> well, you could argue that for the libvirt change as well then
21:05:49 <efried> Yes
21:05:52 <mriedem> (1) reshape to put vgpu inventory on child provider,
21:05:57 <mriedem> (2) add support for multiple vgpu types
21:06:10 <mriedem> the former is the reshape bp, the latter is the vgpu-stein bp
21:06:11 <efried> And every other blueprint ever in the future that makes use of reshape to satisfy some upgrade scenario related to some feature.
21:06:24 <mriedem> we only need to reshape vgpu right now
21:06:31 <mriedem> i think that was the target for that bp
21:06:54 <mriedem> stuff like pcpu/vcpu would be part of a different spec imo
21:07:09 <efried> we're not going to pick out some patch in the middle of a bp series in the X release and retroactively mark it against the reshape bp. So we shouldn't do that here either.
21:07:13 <efried> was my reasoning.
21:07:32 <mriedem> the reshape bp is targeted to stein you know
21:07:40 <mriedem> do you consider it done?
21:07:46 <mriedem> if not, what gets to done?
21:07:59 <efried> FFU script, I think is the only remaining item.
21:08:23 <efried> which I suppose in the scope of the bp is just framework
21:08:38 <efried> and then the feature bps add "plugins" or whatever you want to call them
21:08:40 <mriedem> so FFU before any driver actually does a reshape?
21:08:52 <efried> no, I'm not saying that.
21:09:12 <efried> I'm not saying closing the reshaper bp is a prereq to any other bp that's dependent on it.
21:09:27 <efried> This can't be the first time a bp depends on a subset of another bp
21:09:40 <efried> but actually
21:10:03 <efried> yes, come to think of it, we need to have the ffu script before we can declare the deps complete in this case.
21:10:22 <efried> because otherwise we can't ffu to stein with those features in place.
21:10:24 <efried> right?
21:10:51 <mriedem> well, if you ran it before the drivers did their thing, it wouldn't do anything
21:11:07 <mriedem> i guess in my mind the FFU change would come after b/c that's what happened with the ironic flavors stuff,
21:11:12 <efried> Yup, the placement API endpoint also doesn't do anything until you use it.
21:11:12 <mriedem> but that might not be the best example to follow
21:11:25 <mriedem> anyway, this probably doesn't really matter besides paperwork
21:11:36 <efried> was gonna say, we don't need to take up everyone's time.
21:12:03 <melwitt> so, is the current targeted bp fine then? or are we gonna talk about this more later and let someone know to change the target?
21:12:23 <efried> I will bully mriedem into changing the topic back later.
21:12:36 <melwitt> ok, cool.
21:12:45 <efried> All of it is still targeted for stein until/unless something changes.
21:12:58 <efried> so as matt says, just paperwork
21:13:31 <melwitt> I just put nested-allocation-candidates back in a runway. last patch from the previous runway is -W so I strikethrough'd it as a note
21:13:34 <melwitt> ok
21:13:53 <melwitt> anything else for release news or runways?
21:14:14 <melwitt> #topic Bugs (stuck/critical)
21:14:20 <melwitt> no critical bugs in the link
21:14:27 <melwitt> #link 51 new untriaged bugs (up 1 since the last meeting): https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New
21:14:34 <melwitt> #link 9 untagged untriaged bugs (up 1 since the last meeting): https://bugs.launchpad.net/nova/+bugs?field.tag=-*&field.status%3Alist=NEW
21:14:52 <melwitt> #link bug triage how-to: https://wiki.openstack.org/wiki/Nova/BugTriage#Tags
21:14:59 <melwitt> #help need help with bug triage
21:15:16 <melwitt> Gate status
21:15:34 <melwitt> #link check queue gate status http://status.openstack.org/elastic-recheck/index.html
21:15:49 <melwitt> I think there was a zuul restart earlier in the morning, so things might need rechecking from that
21:15:54 <melwitt> 3rd party CI
21:16:00 <melwitt> #link 3rd party CI status http://ci-watch.tintri.com/project?project=nova&time=7+days
21:16:19 <melwitt> anything else for bugs, gate status, or third party CI?
21:16:34 <melwitt> #topic Reminders
21:16:45 <melwitt> #link Stein Subteam Patches n Bugs: https://etherpad.openstack.org/p/stein-nova-subteam-tracking
21:17:18 <melwitt> I started using the trivial bug section of this etherpad again ^
21:18:09 <melwitt> #link Create etherpads for Forum sessions: https://wiki.openstack.org/wiki/Forum/Berlin2018
21:18:25 <melwitt> create your etherpads if you haven't already
21:18:35 <melwitt> anything else for reminders?
21:18:55 <melwitt> #topic Stable branch status
21:18:57 * efried ist noch nicht approbiert
21:19:38 <melwitt> #link stable/rocky: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/rocky,n,z
21:19:59 <melwitt> mriedem has a note here that we need to do a stable/rocky release
21:20:02 <melwitt> I agree
21:20:44 <melwitt> as for whether we should wait for https://review.openstack.org/#/q/topic:bug/1798188 I'm biased but I think we should. it would be nice to get the status check and release note out
21:21:16 <melwitt> that one is about extra instruction needed to handle nova-consoleauth during a rolling upgrade from queens => rocky
21:21:17 <mriedem> probably
21:21:23 <mriedem> need another core
21:21:24 <mriedem> to sign up
21:21:26 <melwitt> and a status check to help with communication
21:22:05 <melwitt> any other opinions?
21:22:18 <melwitt> I know there's only a few of us here
21:22:46 <melwitt> I'll try to get another core tomorrow morning when more people are around
21:23:15 <melwitt> ok, moving on I guess
21:23:17 <melwitt> #link stable/queens: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/queens,n,z
21:23:33 <melwitt> lots o backports
21:23:43 <melwitt> #link stable/pike: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/pike,n,z
21:23:55 <melwitt> #link stable/ocata: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/ocata,n,z
21:24:02 <melwitt> oh
21:24:10 <melwitt> I was about to say, I wasn't sure if I should keep including ocata
21:24:23 <mriedem> probably don't need to
21:24:32 <melwitt> ok
21:25:13 <melwitt> #info let me know if there are any other stable branch backports you want to get in before we cut stable releases for s-1
21:25:39 <melwitt> anything else for stable branch status?
21:25:57 <melwitt> #topic Subteam Highlights
21:26:05 <melwitt> efried: scheduler?
21:26:16 <efried> #link n-sch meeting minutes http://eavesdrop.openstack.org/meetings/nova_scheduler/2018/nova_scheduler.2018-10-22-14.00.html
21:26:24 <efried> I promised a spec extracting the file format from
21:26:24 <efried> #link kosamara's device-placement-passthrough spec: https://review.openstack.org/#/c/591037/
21:26:24 <efried> while also incorporating some of the tenets of
21:26:24 <efried> #link jaypipes's Rocky provider-config-file proposal: https://review.openstack.org/#/c/550244/
21:26:29 <efried> That has since happened:
21:26:29 <efried> #link Spec: Provider config YAML file https://review.openstack.org/#/c/612497/
21:26:35 <efried> Discussed nrp series which was until recently based at
21:26:35 <efried> #link previous bottom of nrp-in-nova series https://review.openstack.org/#/c/606050/
21:26:42 <efried> mriedem had asked for that to be rebased on
21:26:42 <efried> #link removal of caching scheduler https://review.openstack.org/#/c/611723/
21:26:42 <efried> That has since happened, and both have merged, along with some other cleanup.
21:26:50 <efried> Extraction-wise, cdent proposed the possibility of merging
21:26:51 <efried> #link stub table creator https://review.openstack.org/#/c/600161/
21:26:51 <efried> temporarily, but we decided to give alembic stuff a chance to mature for a bit.
21:27:00 <efried> Also extraction-related, we talked about putting some focus on docs in the placement repo. We pressured^wconvinced tetsuro to take on some of the editing work while we figure out what's needed to get the docs actually building. He has since proposed a couple of patches in that vein:
21:27:07 <efried> #link De-nova-ify doc/README.rst (merged) https://review.openstack.org/612665
21:27:07 <efried> #link De-nova-ify doc/source/index.rst https://review.openstack.org/613200
21:27:07 <efried> And cdent is getting us moving toward
21:27:07 <efried> #link Making tox -ereleasenotes work https://review.openstack.org/613118
21:27:14 <efried> We agreed to start
21:27:14 <efried> #link a new placement-extract etherpad https://etherpad.openstack.org/p/placement-extract-stein-4
21:27:20 <efried> Concern was expressed about backporting
21:27:21 <efried> #link update less in rt https://bugs.launchpad.net/nova/+bug/1729621
21:27:21 <efried> given that the related 0.0 allocation ratio fix came later.
21:27:21 <openstack> Launchpad bug 1729621 in OpenStack Compute (nova) pike "Inconsistent value for vcpu_used" [Undecided,In progress] - Assigned to Radoslav Gerganov (rgerganov)
21:27:25 <efried> END
21:28:06 <mriedem> i've also sent an email to the tripleo and osa teams today,
21:28:14 <mriedem> needing someone to start working on the upgrade work in those projects
21:28:23 <mriedem> the grenade patch is ready to go
21:28:43 <efried> #link mriedem email soliciting osa/tripleo help for extraction http://lists.openstack.org/pipermail/openstack-dev/2018-October/136075.html
21:28:55 <melwitt> thanks, was looking for the link and failing
21:29:18 <melwitt> on that bug, https://bugs.launchpad.net/nova/+bug/1729621 I don't quite understand the backport question?
21:29:18 <openstack> Launchpad bug 1729621 in OpenStack Compute (nova) pike "Inconsistent value for vcpu_used" [Undecided,In progress] - Assigned to Radoslav Gerganov (rgerganov)
21:30:07 <efried> mriedem: that's you. I have only a vague sense of what's going on here, would need to go refresh my memory on all that mess.
21:30:27 <mriedem> remember when the xenapi CI started posting 0 allocation_ratios
21:30:28 <mriedem> ?
21:30:33 <melwitt> yes
21:30:37 <mriedem> it's related to that
21:30:53 <mriedem> we think that regression was somehow caused by the thing that rgerganov is trying to backport
21:31:03 <melwitt> ok, I see. so for queens and earlier we'd need that fix first
21:31:05 <efried> for reference, here's what mriedem said at the time, including a link to code: http://eavesdrop.openstack.org/meetings/nova_scheduler/2018/nova_scheduler.2018-10-22-14.00.log.html#l-125
21:31:06 <mriedem> so i said i'm nervous about that, and we should at least make sure those changes go together
21:31:34 <melwitt> ok, got it
21:32:13 <melwitt> alright, so we know how to move forward there. cool
21:32:29 <melwitt> gmann left a note for the api subteam "No API office hour this week, Not much to share."
21:32:38 <melwitt> #topic Stuck Reviews
21:32:51 <melwitt> nothing on the agenda. anyone in the room have a stuck review to bring up?
21:33:05 <melwitt> ok
21:33:11 <melwitt> #topic Open discussion
21:33:19 <melwitt> few items on the agenda
21:33:32 <melwitt> first one
21:33:33 <melwitt> (mriedem): Do we need a specless blueprint to add a config option to run nova-metadata-api per-cell? There was agreement to add this at the PTG (L412 https://etherpad.openstack.org/p/nova-ptg-stein )
21:33:52 <mriedem> i just don't know how anyone wants that tracked,
21:34:14 <mriedem> i think the change is simply add a config option which if true means the meta-api won't look at the API DB for anything, like instance mappings, and assume everything is local to the cell db
21:34:41 <mriedem> you can, and cern already does, run meta-api per-cell but configured to the api db
21:34:53 <mriedem> even though they are just needlessly querying up to the api to find out the instance is in the cell the yare in
21:34:58 <melwitt> ah, ok
21:35:22 <melwitt> I think I'd err on the side of specless bp since it's a new config option
21:35:33 <mriedem> ok
21:35:59 <melwitt> any other opinions?
21:36:00 <efried> surely should have a bp; is the question whether to have a spec?
21:36:12 <mriedem> i don't think it needs a spec
21:36:18 <mriedem> and no that wasn't the questoin
21:36:23 <mriedem> question was is a specless bp needed
21:36:28 <efried> Okay.
21:36:33 <efried> Yes, IMO.
21:36:36 <mriedem> wfm
21:36:37 <efried> For a new config option.
21:37:01 <mriedem> i just forgot about this for awhile b/c it wasn't being tracked,
21:37:06 <mriedem> so i wanted to know how to track it
21:37:18 <efried> looks like you answered your own question.
21:37:26 <mriedem> just looking for validation
21:37:38 <efried> "Gee, this thing isn't tracked, how should we track it? By tracking it? Cool."
21:37:44 <efried> :P
21:37:53 <melwitt> fair enough to ask if it needs a spec though. I think since this is very straightforward, specless is good. and better than not tracking it
21:38:20 <melwitt> this is just saying "don't waste api db calls on something configured to run local that doesn't need api db calls"
21:38:22 <efried> yuh, was going to say: if we can fit all the words in the bp template, and the spec template sections would be largely "None", no spec.
21:38:33 <melwitt> right
21:38:51 <melwitt> ok, next item
21:38:58 <melwitt> (mriedem): Has anyone made a list of the various cross-project Forum sessions that should include nova participation and determined that we'll have a representative?
21:39:12 <melwitt> this is a good question. I think the answer is no
21:39:33 <melwitt> I know that for the change instance ownership session, that's during the nova project update so I can't go to that
21:39:44 <mriedem> i expect dansmith will be at that
21:39:49 <mriedem> since he wrote os-chown
21:39:52 <mriedem> but,
21:39:53 <melwitt> right
21:39:53 <mriedem> idk
21:40:00 <dansmith> I've said I would already yeah
21:40:11 <mriedem> so it would be good to have an etherpad of the obvious xp sessions and make sure we have reps
21:40:23 <melwitt> yeah, so I think last time I made a list of forum sessions of interest to send to the ML. and I should do that again
21:40:45 <melwitt> and yeah, etherpad, I can do that. can probably use our existing forum etherpad https://etherpad.openstack.org/p/nova-forum-stein
21:41:03 <melwitt> and give a heads up to the ML about it after adding cross-project sessions of interest
21:41:11 <efried> ++
21:41:22 <melwitt> thanks for bringing that up mriedem
21:41:33 <melwitt> ok, last item is from me, a shout out for sundar
21:41:39 <melwitt> (melwitt): The cyborg-nova interaction spec has been updated in response to review comments and is ready for review again: https://review.openstack.org/603955
21:41:58 * efried <== still in the middle of it
21:42:38 <melwitt> yeah, I figured. just an fyi that he's eagerly awaiting everyone's review :)
21:42:59 <melwitt> ok, that's all in the agenda for open discussion. anyone have anything else they'd like to discuss?
21:43:05 <efried> This guy writes good docs. But has a tendency to be... garrulous
21:43:17 * melwitt googles
21:43:30 <melwitt> verbose, yes
21:43:40 <melwitt> :)
21:43:50 <melwitt> ok, if no one has anything else, we can call it a wrap
21:43:55 <melwitt> thanks everyone
21:43:57 <melwitt> #endmeeting