16:00:11 <gibi> #startmeeting nova
16:00:12 <openstack> Meeting started Thu Apr 16 16:00:11 2020 UTC and is due to finish in 60 minutes.  The chair is gibi. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:13 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:15 <openstack> The meeting name has been set to 'nova'
16:00:32 <gibi> o/
16:00:39 <artom> o/
16:00:46 <melwitt> o/
16:00:56 <alex_xu> o/
16:00:57 <dansmith> o/
16:01:36 <bauzas> \o
16:02:02 <gibi> #topic Last meeting
16:02:08 <gibi> #link Minutes from last meeting: http://eavesdrop.openstack.org/meetings/nova/2020/nova.2020-04-09-16.00.log.html
16:02:17 <gibi> Feature Freeze happened last week. We finished 18 blueprints, 1 got FFE, 11 bp got deferred
16:02:34 <gibi> novaclient has been released for Ussuri
16:02:59 <gibi> anything to mention from the last meeting?
16:03:44 <gibi> #topic Release Planning
16:03:53 <gibi> (will go back to bugs in after this)
16:03:59 <gibi> TODOs are tracked in the etherpad #link https://etherpad.opendev.org/p/nova-ussuri-rc-potential
16:04:05 <lyarwood> \o
16:04:08 <gibi> We have one feature open: #link https://review.opendev.org/#/q/topic:bp/policy-defaults-refresh+status:open
16:04:17 <gibi> last week we agreed to finish it until end of this week
16:04:23 <gibi> gmann: where we are with this?
16:04:39 <gmann> sorry forgot about meeting
16:04:42 <gibi> I saw that things are moving but I don't see how much is still needed
16:05:03 <gmann> all the patches need for ussuri are up, few are stuck on gate since yesterday
16:05:10 <gmann> I am trying to get them merged soon
16:05:29 <gmann> doc and release patch is also up which i need to re-work for melwitt comments
16:05:35 <gmann> but that will be last one to merge
16:05:47 <gibi> gmann: cool. so we still has some patches to review but we don't expect new ones
16:06:10 <gmann> yeah most of them are updated for review comment so will be quick to do
16:06:19 <gibi> let's try to approve all the open patches until Friday EOB
16:06:30 <dansmith> I've been trying to grok this whole effort this morning and I'm definitely missing something about what deployers are going to have to do here
16:07:01 <dansmith> hopefully once I figure that out it'll just be some revisions to the spec (or maybe they're already covered in the docs patch, which I haven't read yet)
16:07:40 <gmann> dansmith: i am trying to capture those in this doc with migration plan - https://review.opendev.org/#/c/720129/4/doc/source/configuration/policy-new-defaults.rst
16:07:51 <gibi> as far as I understand the feaure is turned off by default
16:08:02 <dansmith> yeah, I need to read that and see if it clears things up for me
16:08:13 <gmann> yeah it is off by default and we have flag to turn it on without need of overwriting the policy file
16:08:30 <dansmith> gibi: well, I'm more wondering about what we're going to be requiring admins to do at some point before we can complete this migration, not so much the impact of the current ones
16:08:43 <dansmith> gmann: yep, understand that
16:08:55 <melwitt> gmann: I added new comments to the doc patch a little while ago. need to clearly explain whether operators will need to add new keystone roles to use scope types and also explain how end users will need to know how to request scoped tokens from keystone and point to keystone docs for that
16:09:36 <gmann> melwitt: ok, i think pointed to keystone doc but i will check, i agree that is imp
16:09:50 <gibi> dansmith: I see, so what the admins need to do before they can upgrade to V where we remove the old compat code
16:10:13 <melwitt> gmann: yeah, if it is, I missed it. would like to see it very concisely and clearly stated what are the action items for operators
16:10:18 <dansmith> gibi: right, because it sounds like they might have to adjust all their users' roles or something, but again I don't fully grok it
16:10:38 <gmann> melwitt: sure, I will check the comments.
16:10:38 <dansmith> gibi: and since more people are skipping releases these days,
16:10:58 <dansmith> we need to make sure we're not expecting them to have to do somethign where they have to turn the cloud off, migrate a bunch of users, and then turn it back on
16:11:17 <gibi> dansmith: worst case we cannot remove the compat code in V
16:11:21 <dansmith> or worse, some problem where they do that and it affects a user in another service because they have to for nova, or something
16:11:38 <dansmith> gibi: well, worst case we do all this and then never remove it,
16:11:40 <gmann> we are keeping compat code till W. for 2 cycle as this is big change for migration
16:11:47 <dansmith> and then there's two ways, two sets of docs, and confusion :)
16:11:56 <gibi> dansmith: like notifications :)
16:12:02 <dansmith> gibi: yep
16:12:38 <gibi> it is 95% merged so merging the last 5% does not change much for us now
16:12:52 <gibi> but I agree that we need a comprehensive doc
16:13:48 <gibi> if it turns out that it is hard to migrate to the new policies then we have to figure out a way to help
16:14:15 <gibi> but I think not merging the last 5% does not help much with that
16:14:33 <dansmith> I'm not arguing against merging it,
16:14:37 <gmann> i think at some point keystone is also going to remove the support of old role in their policy.
16:15:00 <dansmith> I'm just saying I'm *personally* missing context here, and I hope I'm in the minority, and we need to make sure we've got our attack plan well thought-out
16:15:35 <dansmith> personally missing the big picture and the end game, I mean
16:16:09 <gibi> OK lets work on those attack plans together if it turns out something is missing
16:16:12 <gibi> can we move on?
16:16:25 <dansmith> surely
16:16:37 <gibi> cool
16:16:39 <gibi> Next week (Apr 23) we have to cut RC1
16:16:49 <gibi> please tag any RC critical bug with ussuri-rc-potential tag in launchpad
16:16:56 <gibi> bauzas volunteered to write the release notes prelude. It is due before RC1
16:17:04 <gibi> I will propose an patch with an RPC alias for Ussuri
16:17:10 <gibi> Do we want to make a major compute RPC version bump?
16:17:12 <bauzas> thanks for the reminder
16:17:44 <bauzas> gibi: we generally made such bumps, nope ?
16:18:02 <bauzas> #link https://wiki.openstack.org/wiki/Nova/ReleaseChecklist
16:18:02 <gibi> bauzas: it was a loong time when we bumped to 5.x in compute RPC
16:18:15 <bauzas> I know
16:18:17 <melwitt> there's a patch proposed already for rpc alias fyi https://review.opendev.org/719315
16:18:23 <bauzas> I only remember the old ages
16:18:41 <gibi> https://github.com/openstack/nova/blob/master/nova/compute/rpcapi.py#L392
16:18:42 <sean-k-mooney> gibi: as an fyi ill try and rebase https://review.opendev.org/#/c/706276/ today and after rc1 ill create a similar patch to updated the implemented specs for ussuri
16:19:06 <sean-k-mooney> we forgot to do it last cycle.
16:19:11 <gibi> melwitt: thanks. I did not notice that.
16:19:13 <dansmith> gibi: an rpc bump at this point would likely be difficult
16:19:28 <dansmith> we need to plan that a little further in advance, IMHO
16:19:55 <gibi> dansmith: OK then this answers my question.
16:20:29 <gibi> sean-k-mooney: thanks
16:21:05 <gibi> #info we won't bump compute RPC to 6.0 in Ussuri
16:21:22 <gibi> dansmith: for the future, how much time would need to do such bump?
16:21:56 <artom> Also, and it sucks to leak "downstream" stuff like this, but don't we have to think about what releases operators/vendors are skipping, and make sure to *not* major-bump RPC in those?
16:22:23 <dansmith> artom: no
16:22:30 <sean-k-mooney> we can pin the rpc version so no
16:22:31 <dansmith> gibi: depends on the delta really
16:22:46 <dansmith> artom: people skipping versions can't use rpc compatibility anyway
16:22:52 <artom> dansmith, so in theory we could bump to 6.0 in U, and not break OSP 16 -> 17 FFWD upgrade?
16:23:06 <artom> Oh right, the control plane is down anyways
16:23:10 <dansmith> artom: rpc versions have no impact on an FFU
16:23:21 <dansmith> and even still OSP 16 is T, so no either :)
16:23:23 <artom> dansmith, yep, thanks for setting me straight
16:24:25 <gibi> dansmith: OK, I will add some note to the V release schedule to plan a such bump earlier, maybe around M3
16:24:33 <sean-k-mooney> too gibi question i assume we can move to 6.0 in train but likely would not want to do a major version bump after m3
16:24:43 <sean-k-mooney> * in Victoria
16:25:40 <gibi> sean-k-mooney: so it is need to be planned even eariler?
16:26:02 <dansmith> gibi: I'll have to look at the current delta, but.. is there anything begging for a bump?
16:26:08 <dansmith> I mean, the only reason to do it is really if we desperately need to drop something,
16:26:17 <dansmith> but if not it's just perceptual purity, which isn't a good reason
16:26:29 <bauzas> fwiw https://github.com/openstack/nova/blob/master/nova/compute/rpcapi.py#L372-L379
16:26:31 <bauzas> dansmith: ^
16:26:54 <gibi> dansmith: I have to look at the delta too but I vaguely remember discussing the 6.0 bump for reasons
16:27:08 <dansmith> bauzas: right, none of those are things we need to drop
16:27:26 <bauzas> dansmith: I only see additive changes between 5.1 and now
16:27:28 <dansmith> bauzas: that's my point.. a bunch of additions will be identical in 6.0
16:27:32 <dansmith> right
16:27:43 <bauzas> actually, 5.1 could be debatable
16:27:53 <melwitt> yeah so would more be looking at how many things have notes like "remove this in the next major bump"
16:27:57 <bauzas> dansmith: I agree
16:28:09 <bauzas> except 5.1 maybe
16:28:09 <dansmith> melwitt: not really, those are often no-ops anyway
16:28:19 <dansmith> melwitt: more like thing like 5.1, but even that is just uuber minor, IMHO
16:28:25 <bauzas> right
16:28:35 <melwitt> I guess I thought eventually would be looking to clean them up
16:28:36 <dansmith> I mean things like "if <5.5, then do an extra DB lookup to reconstruct some information we're missing"
16:28:40 <bauzas> now we objectified all rpc apis, changes are mostly additive
16:28:56 <melwitt> oh
16:28:58 <dansmith> melwitt: right, that's what I'm saying.. just cleanups aren't worth it.. things that actually have an impact are why we need to
16:29:17 <melwitt> ok
16:29:24 <gibi> OK. I made a note to myself to double check it but let's move on
16:29:26 <bauzas> moving on ? :)
16:29:28 <bauzas> heh
16:29:43 <gibi> anything else for the release planning before we jump back to bugs?
16:29:44 <dansmith> moving....on.
16:30:07 <gibi> #topic Bugs (stuck/critical)
16:30:13 <gibi> No critical
16:30:24 <gibi> #link 71 new untriaged bugs (-40 since the last meeting): https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New
16:30:36 <gibi> good progress to eating our backlog
16:30:47 <gibi> but we keep continue as RC1 is close
16:30:53 <gibi> RC critical bugs are tagged with ussuri-rc-potential #link https://bugs.launchpad.net/nova/+bugs?field.tag=ussuri-rc-potential
16:31:17 <gibi> there is now 1 bug on that list
16:31:35 <gibi> it has a patch up and I gave review feedback
16:31:50 <gibi> I'm not 100% sure it is that critical though
16:31:57 <bauzas> not RC holding
16:32:25 <bauzas> i mean it's not a U regression
16:32:37 <bauzas> but I thought it was worth looking at it before we branch
16:33:07 <gibi> sure
16:33:27 <gibi> somebody added an bug to the agenad
16:33:36 <gibi> how to solve the bug ? #link https://bugs.launchpad.net/nova/+bug/1841932 Could we add compat for os:hide_hypervisor_id and reference that in docs and code?so that we can use AggregateInstanceExtraSpecsFilter and hide_hypervisor_id at the same time.
16:33:36 <openstack> Launchpad bug 1841932 in OpenStack Compute (nova) "hide_hypervisor_id extra_specs in nova flavor cannot pass AggregateInstanceExtraSpecsFilter" [Undecided,Expired]
16:33:57 <bauzas> leave it for open discussion ?
16:34:22 <gibi> OK, I hope the person added it to the agenda will show up until then
16:34:36 <gibi> any other bug related business?
16:34:41 <sean-k-mooney> so the problem with that extra spec is we did not namespace it
16:34:57 <sean-k-mooney> so it breaks the AggregateInstanceExtraSpecsFilter
16:35:17 <gibi> OK so it is not a regression at least
16:35:23 <sean-k-mooney> no
16:35:25 <gibi> good
16:35:27 <gibi> moving on
16:35:32 <tframbo> yeah ,i added the bug
16:35:48 <gibi> tframbo: let's discuss it a bit at the end of the meeitng
16:35:51 <gibi> #topic Stable Branches
16:35:53 <bauzas> the whole hide_hypervisor_id thing is... hacky :p
16:35:56 <tframbo> ok
16:36:00 <gibi> lyarwood any news?
16:36:16 <gibi> we discussed a need for a train release last week
16:36:29 <bauzas> tl;dr: shhhhht, QEMU, don't tell the nvidia driver I don't have the right to use you
16:36:55 <melwitt> stable train and stein were recently broken bc placement started requiring python 3.6 and our func test stuff in tox.ini was pulling placement from master,
16:37:11 <melwitt> train is fixed and stein fix is en route to the gate
16:37:18 <gmann> #link https://review.opendev.org/#/c/719121/
16:37:23 <gibi> melwitt: thanks
16:37:35 <gmann> hope it get node in gate
16:37:58 <melwitt> yeah there might be some gate issue, I've been discussing in -infra. might be a nova bug even. yay! (not)
16:38:18 <gibi> it seems lyarwood is not here I will ping him about the stable release tomorrow
16:38:20 <lyarwood> yeah sorry ^ I've also hit a few other issues slowing things down
16:38:59 <lyarwood> we should still be able to release before RC (iirc that was the plan)
16:39:21 <gibi> lyarwood: cool thanks
16:39:37 <gibi> #topic Sub/related team Highlights
16:39:50 <gibi> API (gmann)
16:39:56 <gibi> anything besides the policy work?
16:40:17 <gmann> no, all what we discussed earlier  .
16:40:26 <gibi> cool
16:40:27 <gibi> moving on
16:40:34 <gibi> #topic Stuck Reviews
16:40:39 <gibi> (bauzas) https://review.opendev.org/#/c/589085/8 (Merging virt API changes after FeatureFreeze)
16:41:00 <bauzas> nothing crucial here but I think we need a consensus on things we can accept
16:41:24 <bauzas> tl;dr: I'm touching the virt API signature of revert_resize and resize')
16:41:25 <gibi> we need to choose between allowing the virt driver interface to change post FF and allow the same interfacechange on stable/ussuri branch later
16:41:38 <bauzas> both are internal APIs but are in use by out-of-tree drivers
16:41:57 <bauzas> so for convenience (since virt APIs aren't public), we notify them
16:42:06 <bauzas> there are two options
16:42:20 <bauzas> 1/ we consider it's a breaking change hence not acceptable post FF
16:42:37 <bauzas> and in this case, we shouldn't allow this to be backportable
16:43:02 <bauzas> 2/ we assume this isn't a breaking change and in this case, we also consider it as acceptable post-FF
16:43:18 <gibi> just looking at the interface change patch it feels lower risk to do it now than to do it on the stable branch
16:43:26 <bauzas> and the corollar being, if this punts to V, this can be backportable to U
16:43:35 <bauzas> so, 1/ or 2/ ?
16:43:46 <gibi> 2/
16:44:07 <bauzas> I thought we had disagreements on such things
16:44:17 <bauzas> I won't vote on it, since I'm involved in the change
16:44:20 <melwitt> and there is no desire to backport this earlier than ussuri right? I see that the bug was reported a long time ago
16:44:30 <bauzas> (but you get my opinion by seeing the change)
16:44:45 <bauzas> melwitt: I honestly have no energy for it
16:45:03 <bauzas> or, in other words, this wouldn't be backported upstream
16:45:15 <stephenfin> yeah, maybe downstream. Can't see us doing that upstream, tbh
16:45:23 <melwitt> ok. well, the change looks simple at least. so seems low risk
16:45:37 <bauzas> melwitt: but your question remains, if we go with 2/, in theory we could accept virt API changes to be backportable down to T or whatever
16:46:22 <bauzas> or we just say "no policy, it's case-by-case" and we move on
16:46:56 <gibi> if I were a out of tree virt driver maintainer I would expect changes on that interface to happen more at major version than at minor version
16:47:18 <stephenfin> that's where I'm at too ^
16:47:20 <melwitt> yeah, agree with that
16:47:37 <gibi> (for the record I'm not maintainting out of tree drivers)
16:47:56 <gibi> so we agree to change the interface then do it where it is expected to change
16:48:07 <stephenfin> but, with that said, if this was a more critical issue with a move operation that affected more people, I imagine out-of-tree drivers would have to deal with it
16:48:12 <sean-k-mooney> stephenfin: i dont really want use to do it downstream either
16:48:43 <bauzas> stephenfin: out-of-tree driver maintainers would have to maintain compatibility with the backport, whatever the use is
16:48:58 <bauzas> it's not about the use of the parameter
16:49:17 <bauzas> it's just that if we backport it to Train, Stein or Rocky, then we break them
16:49:27 <bauzas> (for resize and revert resize here)
16:49:28 <sean-k-mooney> bauzas: unless you catch the type error and call the function again without the parmater which we have dont in the past
16:49:30 <gibi> dansmith: do you have a hard NO against merging the interface change now? (I'm asking you as you expressed a preference to not do it in U)
16:49:49 <sean-k-mooney> that would support out of tree driver but i dont think we shoudl have to do that
16:49:58 <bauzas> we can honestly defer it to V if we are able to merge it sooner than later
16:50:06 <bauzas> sean-k-mooney: I'm opposed to it
16:50:22 <bauzas> sean-k-mooney: there is one thing to notify and have a gentleman agrement
16:50:39 <bauzas> there is another thing to implement some kind of public and maintained API for them
16:50:48 <stephenfin> yeah, that would imply actual support
16:51:15 <bauzas> okay, so, I don't hear any disagreement on merging it post-FF if we can
16:51:21 <bauzas> and if we can't, no backport to U
16:51:27 <bauzas> I'm cool with both things
16:51:36 <sean-k-mooney> i know im jsut saying what we have done in the past. im pretty sure we did this recently for one of the migration specs. my preference is to defer to V
16:51:54 <sean-k-mooney> with no backport
16:51:57 <stephenfin> Cool. I'll take another look at that in the morning and send it through so
16:52:07 <bauzas> let's just leave a chance of this thing to be reviewed during this RC period and if we are not able to merge it, merge it in V
16:52:22 <bauzas> stephenfin: the last patch needs a revision, hold your pen
16:52:37 <gibi> #info give a chance to https://review.opendev.org/#/c/589085/ to merge before RC1
16:52:43 <bauzas> I think we're mostly on agreement, let's move on
16:52:59 <bauzas> gibi: also, the consensus is "don't backport any virt API changes"
16:53:09 <bauzas> which is a solid argument
16:53:33 <gibi> let's discuss that part of the agreemet at another time.
16:53:38 <bauzas> all good, thanks folks
16:53:42 <gibi> moveing on
16:53:43 <gibi> #topic Open discussion
16:53:52 <gibi> (gibi): Virtual PTG planning. #link http://lists.openstack.org/pipermail/openstack-discuss/2020-April/014148.html
16:54:01 <gibi> I need to book slots in the common schedule so we need to know how much slots we need, and what time slots we want to use.
16:54:13 <gibi> doodle link is in the mail
16:54:47 <gibi> and if you have any feeling about the amount of time we need the please ping me on #openstack-nova later
16:55:23 <gibi> tframbo: your turn
16:55:31 <gibi> #link https://bugs.launchpad.net/nova/+bug/1841932
16:55:31 <openstack> Launchpad bug 1841932 in OpenStack Compute (nova) "hide_hypervisor_id extra_specs in nova flavor cannot pass AggregateInstanceExtraSpecsFilter" [Undecided,Expired]
16:55:35 <bauzas> I'm sad the Foundation only provided a week slot
16:55:40 <bauzas> but meh
16:55:47 <tframbo> Maybe we could add compat for "os:hide_hypervisor_id” like other extra specs and reference that in docs and code to solve it?
16:56:20 <sean-k-mooney> tframbo: we coudl specical case for that yes for backport only
16:56:39 <bauzas> tframbo: can't you just use aggregates with random keys ?
16:56:41 <sean-k-mooney> but i think we shoudl be removing support for unnamespaced extra specs form the filter
16:57:23 <bauzas> I'm personnally opposed to expose any single libvirt knob as an image metadata property
16:57:47 <sean-k-mooney> bauzas: the image metadata is how we are ment to expose them
16:57:55 <sean-k-mooney> its why this feature originally only supported that
16:58:03 <sean-k-mooney> and not extra specs
16:58:13 <bauzas> sean-k-mooney: no
16:58:13 <sean-k-mooney> the extra sepcs supprot was added after
16:58:25 <bauzas> you can achieve the same thing without automatically exposing your capabilities
16:58:41 <bauzas> we have traits, we have filters that do this for you
16:58:55 <sean-k-mooney> this change how the vm is virutalsed
16:58:59 <bauzas> I don't see the need to add yet another knob
16:59:02 <sean-k-mooney> so trait wont help
16:59:11 <gibi> we are running out of time
16:59:13 <bauzas> that's a scheduling problem
16:59:18 <bauzas> not a boot issue
16:59:33 <sean-k-mooney> lets talk about this on #openstack-nova
16:59:35 <gibi> tframbo: I see that bauzas and sean-k-mooney has oppinion about the bugfix so let's talk to them on #openstack-nova
16:59:36 <bauzas> yeah, agreed, let's punt this to -nova
16:59:49 <gibi> thanks everyone
16:59:56 <tframbo> ok
17:00:00 <sean-k-mooney> o/
17:00:01 <gibi> #endmeeting