21:00:26 <efried> #startmeeting nova
21:00:27 <openstack> Meeting started Thu Aug  1 21:00:26 2019 UTC and is due to finish in 60 minutes.  The chair is efried. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:28 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:30 <openstack> The meeting name has been set to 'nova'
21:00:38 <takashin> o/
21:01:08 <Luzi> O/
21:01:24 <mriedem> .
21:01:48 <melwitt> o/
21:02:46 <efried> #link agenda https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting
21:03:02 <efried> #topic Last meeting
21:03:02 <efried> #link Minutes from last meeting: http://eavesdrop.openstack.org/meetings/nova/2019/nova.2019-07-25-14.00.html
21:03:51 <efried> action from last time
21:03:51 <efried> efried to (delegate or) ensure releases as appropriate for python-novaclient and os-vif
21:03:51 <efried> ✔
21:04:13 <efried> other old business?
21:04:32 <efried> #topic Release News
21:05:03 <efried> spec freeze exceptions will be discussed in opens
21:05:16 <efried> other release news?
21:05:40 <efried> #topic Bugs (stuck/critical)
21:05:40 <efried> No Critical bugs
21:05:40 <efried> #link 67 new untriaged bugs (-0 since the last meeting): https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New
21:05:40 <efried> #link 2 untagged untriaged bugs (-1 since the last meeting): https://bugs.launchpad.net/nova/+bugs?field.tag=-*&field.status%3Alist=NEW
21:05:48 <efried> anything on bugs?
21:06:07 <efried> #topic Gate status
21:06:07 <efried> #link check queue gate status http://status.openstack.org/elastic-recheck/index.html
21:06:07 <efried> #link 3rd party CI status (seems to be back in action) http://ciwatch.mmedvede.net/project?project=nova
21:07:09 <efried> #topic Reminders
21:07:14 <efried> any?
21:07:29 <mriedem> general reminder,
21:07:37 <mriedem> but if anyone wants to hack on compute osc gaps https://etherpad.openstack.org/p/compute-api-microversion-gap-in-osc
21:07:41 <mriedem> and want help or whatever ping me
21:07:46 <mriedem> i've been semi busy in osc lately
21:08:30 <efried> cool
21:08:43 <efried> #topic Stable branch status
21:08:43 <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
21:08:43 <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
21:08:43 <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
21:08:57 <mriedem> quite a few stein and rocky changes just flushed this week
21:09:15 <mriedem> lots of rocky and queens yet
21:09:50 <efried> cool
21:10:05 <efried> #topic Sub/related team Highlights
21:10:05 <efried> Placement (cdent)
21:10:05 <efried> #link latest pupdate http://lists.openstack.org/pipermail/openstack-discuss/2019-July/008053.html
21:10:43 <efried> Pretty quiet in placement-land, at least for stuff nova cares about
21:11:01 <efried> API (gmann)
21:11:01 <efried> Did not push the updates on ML. Main updates are below:
21:11:01 <efried> 1. API cleanup code is ready for review and it is on runway.
21:11:01 <efried> 2. I am working on 'Default policy refresh' and making first API policies (os-services) seq of changes up. That will be used to get early feedback and direction we will follow for all the API policies. I should be ready with that by Monday.
21:11:01 <efried> Some followup nits of merged spec are fixed in this, need review on this spec-nits-update patch- https://review.opendev.org/#/c/669196/.
21:11:01 <efried> 3. There are few more API related BPs up for review or under review (you can fetch the links from API updates ML of last week).
21:11:46 <efried> (1st person above is gmann of course)
21:11:56 <efried> #topic Stuck Reviews
21:11:59 <efried> any?
21:12:35 <efried> #topic Review status page
21:12:35 <efried> #link http://status.openstack.org/reviews/#nova
21:12:35 <efried> Count: 461 (-1); Top score: 1352 (+21)
21:12:35 <efried> #help Pick a patch near the top, shepherd it to closure
21:13:08 <efried> #topic Open discussion
21:13:08 <efried> Train Spec Freeze Exception Process
21:13:30 <efried> let's do
21:13:30 <efried> #link Nova Part of Image Encryption: https://review.opendev.org/#/c/608696
21:13:30 <efried> first since Luzi is here
21:13:39 <efried> Luzi: your mic
21:13:43 <Luzi> hi o/
21:14:48 <Luzi> first: I answered mriedem's questions -  it's a good thing to add a trait - i also read your comment efried
21:15:41 <Luzi> mriedem, was that (trait and upgrade) your only concerns?
21:15:50 <mriedem> my main concerns were around handling upgrades and support for non-libvirt computes
21:15:53 <mriedem> i think the trait solves that
21:16:03 <mriedem> trait + some request filter thing
21:16:27 <mriedem> as for the rest, johnthetubaguy and dansmith were most vocal in the forum session from the nova team from what i remember so i'll defer to them on whether or not this should be an exception for train
21:16:30 <Luzi> yes trait + filter, I would add this to the spec
21:16:40 <mriedem> it also depends on the glance and cinder stuff getting done right? or at least glance/barbican?
21:16:53 <Luzi> the cinder spec is merged
21:17:02 <mriedem> sure, but that doesn't mean the code is going to make train
21:17:12 <Luzi> and barbican is working on the secret consumer API
21:17:16 <mriedem> iow, this smells like backlog for U to me, but i'm not blocking it
21:17:27 <mriedem> and like i said i'll defer to john and dan
21:17:39 <efried> mriedem: How long should we be waiting for johnthetubaguy and dansmith to respond?
21:18:00 <mriedem> dan is out this week, and i wouldn't expect him to want to jump on this post-spec freeze first thing when he's back next week (if at all)
21:18:05 <mriedem> john....idk, he's streaky
21:18:22 <mriedem> dragging FFEs past the deadline also sucks
21:18:27 <mriedem> b/c why have a deadline.
21:18:33 <efried> Well
21:18:48 <efried> imo it's for things like this that were really close and just needed a little push over the edge
21:19:03 <mriedem> well i guess i'd try to get dan to take a look by end of next week
21:19:16 <mriedem> once the upgrade related stuff and non-libvirt considerations are written up
21:19:31 <efried> to me, this is a pretty small an non-invasive effort, and obviously the deps have to be met or it won't go, but that's not on us.
21:19:39 <efried> okay, wfm
21:19:52 <mriedem> "small an non-invasive effort" famous last words
21:20:00 <efried> I know, I know.
21:20:05 <mriedem> anything involve multiple nova services let alone multiple openstack services is not small....
21:20:22 <mriedem> like i said i'm not blocking
21:20:48 <efried> Point is, if all the other stars align, it would suck for it to not make Train purely because "we didn't get the spec approved by the freeze date".
21:21:02 <efried> I would rather punt an approved spec to U
21:21:17 <mriedem> i don't disagree
21:21:39 <mordred> I agree with everything
21:21:40 <mriedem> don't want this to become another john hopkins trusted certs thing
21:21:55 <mriedem> which they pushed for 4 releases or something, landed a thing and then lost their grant and moved on
21:22:05 <mriedem> so who knows if anyone is using ^ or it works anymore
21:22:43 <efried> so okay, we have a plan:
21:22:43 <efried> #action Luzi to update spec per comments
21:22:43 <efried> #action dansmith (and if possible johnthetubaguy) to review and make a call by end of next week
21:22:43 <efried> mriedem is +0 and I'm in favor, so whatever Dan (& John) say goes.
21:22:57 <efried> melwitt: do you have an opinion?
21:22:59 * mriedem puts curmudgeon pin away
21:23:04 <efried> since you're the other core in the room?
21:23:19 <melwitt> not really, I haven't been through that spec
21:23:29 <efried> Okay.
21:23:33 <mriedem> would be cool if mnaser et al ops could read it,
21:23:45 <mriedem> since in berlin there was a session about encrypted * and this was one of the items
21:23:53 <mriedem> total hands off user encrypted images
21:24:06 <efried> I added mnaser to the review
21:24:28 <efried> Luzi: Anything else to bring up before we move on?
21:24:36 <Luzi> no
21:24:53 <efried> okay, next:
21:24:53 <efried> #link Use PCPU and VCPU in One Instance: https://review.opendev.org/#/c/668656/
21:25:50 <mriedem> this came in pretty late
21:25:52 <mriedem> july 2
21:26:27 <efried> Where we're at on this one is that stephenfin and sean (and we think alex) have agreed on the approach
21:26:27 <efried> and have come up with and documented in the
21:26:27 <efried> #link blueprint https://blueprints.launchpad.net/nova/+spec/use-pcpu-and-vcpu-in-one-instance
21:26:27 <efried> a set of provisos/conditions that must be met
21:27:08 <efried> obviously it's got a hard dep on cpu-resources; ^ states that that must be done a couple weeks before feature freeze or this one dies.
21:28:12 <mriedem> but neither of them have voted on it
21:28:17 <mriedem> at least the latest
21:28:36 <efried> no, it was just updated
21:29:02 <efried> ...per guidance from Stephen & Sean.
21:29:18 <mriedem> i haven't read it in detail nor would i probably grok it
21:29:24 <mriedem> so i'll defer to dan (again)
21:29:30 <mriedem> and he'll ugh it all day long probably
21:29:37 <efried> Was Dan invoved on the cpu-resources work?
21:29:50 <mriedem> pretty sure he was involved in the shape of that spec
21:29:55 <mriedem> at least when jay was involved
21:31:11 <efried> I don't see him involved in that spec review other than one comment back in April.
21:31:17 <mriedem> plus irc,
21:31:20 <mriedem> plus ptg/summit
21:31:44 <mriedem> whatever, anyway, if you ask me i'll say goto dansmith
21:31:57 <mriedem> and he'll probably say goto /dev/null
21:32:08 <mriedem> but he can speak for himself when he's back :)
21:32:15 <efried> Okay.
21:32:58 <efried> I should probably recuse myself here because a) I don't understand the technical side very well, and b) this is an Intel ask.
21:33:24 <efried> so if you're punting, then I guess
21:33:24 <efried> #action dansmith to decide on all the things next week.
21:33:37 <efried> Any other open discussion before we blow this popsicle stand?
21:33:47 <melwitt> I have a thing
21:33:54 <efried> hit it
21:34:04 <melwitt> would like for ppl to look over https://blueprints.launchpad.net/nova/+spec/policy-rule-for-host-status-unknown and let me know if they think it still needs a spec or not
21:34:39 <efried> Heh. Spec freeze exception by killing spec.
21:34:40 <melwitt> because the original proposal evolved into a policy rule thing and I have seen us do new policy rules as wishlist bug before
21:35:07 <melwitt> haha, yeah. I'm not getting my hopes up but wanted to throw it out there, in case it is no longer spec worthy
21:35:30 <efried> oh, this one
21:35:31 <melwitt> so if anyone has feedback about that, let me know. doesn't have to be right now
21:35:33 <mriedem> you mean like https://review.opendev.org/#/c/526558/
21:35:48 <melwitt> yeah that's the example I was thinking about
21:36:25 <efried> I thought this one was under debate for reasons of "do we really want to expose UNKNOWN"
21:36:35 <mriedem> this is different
21:36:41 <mriedem> this is expose host_status but only if UNKNOWN
21:36:49 <melwitt> the debate was about overwriting the cosmetic instance "status"
21:36:49 <mriedem> not change server status to UNKNOWN if host_status is UNKNOWN
21:36:53 <melwitt> right
21:36:54 <mriedem> which is much more targeted
21:37:21 <efried> is there code for this?
21:37:40 <melwitt> no but there can be. I didn't do anything yet
21:37:53 <mriedem> i'm not against this,
21:38:00 <melwitt> the only potentially weird area on this one is, what to show if host_status it not UNKNOWN. I was thinking empty string rather than omitting the field
21:38:01 <efried> no microversion right?
21:38:07 <mriedem> i think the proposed policy rule needs to conform to the new standards but that's impl details
21:38:16 <mriedem> i also have performance concerns when listing servers, but that's impl
21:38:31 <melwitt> no microversion
21:38:44 <mriedem> if you're adding a new field to the response by default that's a change
21:38:51 <mriedem> host_status was new in 2.16 from what i remember
21:39:18 <mriedem> yup (man my long term memory is outstanding)
21:39:51 <mriedem> so would it only show up if >= 2.16 and policy passes?
21:39:58 <melwitt> by default for whom? I mean, host_status is there for admins by default. are you saying making it be there by default for non admins would be considered an API change?
21:39:59 <melwitt> yeah
21:40:14 <mriedem> i meant regardless of microversion
21:40:26 <mriedem> if you're >= 2.16 then that's less of an issue
21:40:40 <mriedem> idk about just returning an empty string
21:40:40 <melwitt> oh. yeah, when I said no microversion I meant not adding a new microversion for this
21:41:01 <mriedem> we have some apis that don't return fields based on policy
21:41:09 <melwitt> yeah, I'm not sure either. I was thinking it might be weird to return the field only if it is UNKNOWN
21:41:26 <mriedem> if only there were a spec to discuss this in review....
21:41:39 <melwitt> because that is not really based on policy. it would be unpredictable
21:41:55 <melwitt> ok, guess that answers my question
21:41:57 <mriedem> well,
21:42:06 <efried> gibi is back next week too, and it was based on his feedback that the latest PS was pushed, yah?
21:42:09 <mriedem> this would be unpredictable w/o a microversion depending on which cloud you're talking to anyway
21:42:33 <mriedem> the docs say, "This attribute appears in the response only if the policy permits."
21:42:41 <mriedem> so i think that means it's cool to not show it if you don't pass policy
21:42:51 <mriedem> and if you do pass policy but the value is not UNKNOWN, we still don't show it
21:43:06 <melwitt> ok, if that is kosher, then that would be easier for me
21:43:08 <mriedem> either way the client needs to handle it
21:43:22 <mriedem> i can leave some comments on the bp whiteboard
21:43:34 <melwitt> thanks
21:44:30 <efried> are we done then?
21:44:43 <melwitt> yeah, I think I'm good
21:44:58 <efried> Okay. Thanks all
21:44:58 <efried> o/
21:44:58 <efried> #endmeeting