16:00:16 <gibi> #startmeeting nova
16:00:17 <openstack> Meeting started Thu Jul  2 16:00:16 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:18 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:20 <openstack> The meeting name has been set to 'nova'
16:00:27 <gibi> o/
16:00:35 <dansmith> o/*
16:00:35 <lyarwood> \o
16:00:38 <gmann> o/
16:00:39 <bauzas> \o (even if a bit done)
16:01:03 <stephenfin> o/
16:01:24 <gibi> let's get started
16:01:26 <gibi> #topic Bugs (stuck/critical)
16:01:38 <gibi> no critical bug
16:01:43 <gibi> #link 31 new untriaged bugs (+4 since the last meeting): https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New
16:01:48 <gibi> please look at the untriaged bug list and try to push some bugs forward
16:02:03 <gibi> is there any bug that we need to talk about today?
16:02:09 <gmann> one focal bug for mysql 8.0 - https://review.opendev.org/#/c/738723/
16:02:24 <gmann> this is ready for review, I tested in https://review.opendev.org/#/c/738126/
16:03:32 <gibi> gmann: looks good. I will check it after the meeting
16:03:40 <gmann> thanks
16:04:34 <lyarwood> gmann: is focal otherwise stable btw?
16:04:46 <lyarwood> gmann: before I dropped offline I recall there were volume attach/detach issues
16:05:07 <gmann> lyarwood: no, we have one more things for volume detach failing on focal, i will discuss in nova channel for details
16:05:13 <gmann> lyarwood: yeah
16:05:22 <lyarwood> ack cool, happy to help with that
16:05:30 <gmann> #link https://bugs.launchpad.net/nova/+bug/1882521
16:05:30 <openstack> Launchpad bug 1882521 in OpenStack Compute (nova) "Failing device detachments on Focal" [High,New]
16:05:32 <gmann> lyarwood: thanks
16:05:36 <gibi> cool
16:05:43 <gibi> #topic Runways
16:05:49 <gibi> etherpad #link https://etherpad.opendev.org/p/nova-runways-victoria
16:06:01 <gibi> we have bps in all three slots
16:06:10 <gibi> bp/add-emulated-virtual-tpm got some feedback from me today
16:06:18 * stephenfin is working on that atm
16:07:04 <gibi> thanks stephenfin
16:07:09 <gibi> the second one is
16:07:11 <gibi> bp/max-concurrent-snapshots has been approved and moves through the gate
16:07:24 <gibi> so that slot will be freed soon
16:07:28 <aarents> gibi: yep on the gate
16:07:32 <aarents> o/
16:07:35 <gibi> thank you for the effort
16:07:51 <gibi> and last but not least we have
16:07:51 <gibi> the second part of bp/use-pcpu-and-vcpu-in-one-instance needs review
16:08:36 <stephenfin> It's been rebased and updated to hopefully address comments, but I haven't gotten to it yet. The first four patches are good to go though
16:08:46 <stephenfin> (they're mine so I can't really review)
16:09:01 <gibi> stephenfin: I saw you pinged alex_xu about it
16:09:17 <gibi> I will also try to look at that series too
16:10:27 <gibi> the queue itself is empty so if somebody has some patch series that is ready for review then please add it to the etherpad
16:10:49 <gibi> any other business about runways?
16:11:48 <gibi> #topic Release Planning
16:11:54 <gibi> 4 weeks until Victoria M2
16:12:10 <gibi> so 4 weeks until spec freeze
16:12:39 <gibi> I quickly looked at the specs today and all the open specs has negative feedback on it
16:13:19 * bauzas needs to do homework ftw
16:13:20 <gibi> right now we have 10 approved blueprints for Victoria which is half of the Ussuri number
16:13:49 <gibi> but will not be sad if we don't reach the Ussuri level
16:14:36 <gibi> anything else about the release?
16:15:50 <gibi> #topic Stable Branches
16:16:12 <lyarwood> #link http://lists.openstack.org/pipermail/openstack-discuss/2020-July/015747.html
16:16:38 <lyarwood> stable/ocata is now unmaintained, will move to EOL in 3 months if we don't see any activity
16:17:03 <lyarwood> thanks to gmann, elod and others for working on fixing the various issues we've seen over the last 4 weeks btw
16:17:18 <gibi> yes, big thanks for that
16:17:20 <lyarwood> stable/rocky should hopefully be GREEN shortly
16:17:29 <lyarwood> and stable/queens shortly after that
16:17:40 <gibi> awesome
16:17:46 <gmann> lyarwood: do we need release before making ti unmaintained? i mean any things merged after last ocata release
16:18:00 <lyarwood> gmann: we don't release from -em branches right?
16:18:02 <melwitt> what's the latest issue preventing green? I lost track of if/what I could help review
16:18:02 <gibi> EM does not do releases
16:18:16 <lyarwood> melwitt: g-api isn't starting on subnodes
16:18:26 <elod> in Ocata, the tempest is not green
16:18:27 <gmann> lyarwood: humm we do not know as this is first unmaintained branch
16:18:33 <elod> stestr issue
16:18:34 <lyarwood> melwitt: https://review.opendev.org/#/c/739072/ being tested https://review.opendev.org/#/c/739074/
16:19:03 <gmann> yeah stestr things is kind of not solvable things
16:19:12 <melwitt> elod: I've been wondering if we should propose upper-constraints bumps for subunit 1.4.0 on stable branches :/
16:19:37 <melwitt> lyarwood: ack thanks
16:19:40 <lyarwood> gmann: https://docs.openstack.org/project-team-guide/stable-branches.html#extended-maintenance - it's documented that we don't release from -em branches, I don't see why we would need a final release tbh.
16:19:50 <elod> melwitt: subunit? for which branch?
16:20:01 <bauzas> lyarwood: we said we NEVER would
16:20:17 <bauzas> if people want to maintain a EM branch, up to them
16:20:18 <elod> one comment for g-api, i think that will make pike work, too
16:20:27 <bauzas> but no release is the price to pay
16:20:33 <melwitt> elod: oh sorry, I thought by stestr you meant the subunit parser problem. nevermind me if that's not the case
16:20:36 <gmann> lyarwood: ok. i was thinking to have tag like ocata-eol etc like this  - https://review.opendev.org/#/c/719097/1
16:20:51 <bauzas> and fwiw, if nobody steps up caring about stable/ocata, then we can just tell "bye"
16:20:55 <lyarwood> gmann: yeah we will tag but that isn't a formal release AFAIK
16:20:59 <gmann> bauzas: exactly
16:21:07 <bauzas> looks like fixing ocata isn't trivial
16:21:10 <elod> melwitt: oh, i see, btw, in stein, there's the subunit.parser issue as well :)
16:21:16 <gmann> lyarwood: ah yeah, tag not release. sorry
16:21:20 <bauzas> so it shouldn't be a community-driven effort then
16:21:39 <bauzas> lyarwood: I thought we said no tags too tbh
16:21:42 <melwitt> elod: yeah, I was noticing that and contemplating an upper-constraints bump because of it :P
16:21:46 <lyarwood> bauzas: just one for EOL
16:21:51 <bauzas> oh this
16:21:55 <gmann> right, its too many things to fix in ocata and more than that maintaining that as lot of CI/CD changes happening
16:21:58 <bauzas> well, sure
16:22:00 <lyarwood> yeah, nothing for unmaintained
16:22:11 <elod> bauzas: we've tried fixing ocata, but it's a catch 22 now :S
16:22:18 <bauzas> then...
16:22:19 <gmann> yeah make sense, just for eol not for unmantained
16:22:32 <bauzas> the ship has already sailed, apparently.
16:22:48 <lyarwood> well it's just going to sit there either way tbh
16:22:57 <lyarwood> if someone wants to try they can in the next 3 months
16:22:59 <gibi> I think the ocata situation is well summarized by lyarwood. I fully agree with that
16:23:24 <gibi> is there anything else stable related?
16:23:30 <lyarwood> Nothing from me thanks
16:23:52 <elod> maybe the cherry-pick check
16:23:59 <elod> https://review.opendev.org/#/c/738271/
16:24:03 <gmann> this thread can give details on CI/CD issues on ocata. http://lists.openstack.org/pipermail/openstack-discuss/2020-May/015112.html
16:24:41 <lyarwood> elod: TIL that we even had this, I'll review your fix now.
16:25:05 <gibi> lyarwood: this become a thing while you were away
16:25:06 <elod> lyarwood: thanks!
16:25:17 <gibi> gmann: ack, thanks
16:25:18 <elod> it's in ussuri and train,
16:25:38 <lyarwood> awesome :)
16:25:38 <elod> and does some false fail in stable patches there
16:25:50 <gibi> OK, moving forward :)
16:25:53 <gibi> #topic Sub/related team Highlights
16:25:59 <gibi> API (gmann)
16:26:09 <gmann> one thing to share
16:26:12 <gmann> #link https://review.opendev.org/#/c/735068/
16:26:35 <gmann> ^^ this is a tricky APi change and for me it is more kind of changing the policy/config default
16:27:27 <gmann> it is changing the 200->400 for set flavor if the requested project validation is 403 from keystone
16:28:02 <gmann> and fix from user side is to allow GET /projects permission to users to continue success on set flavor API.
16:28:37 <gmann> i think we need to add a deprecation warning at least here and microverion not needed. but i would like to hear more feedback on that
16:29:09 <melwitt> oh, that's an old thing from when the project existence stuff was added. if not enough permission to check the project, assume that things are OK (old behavior)
16:29:18 <gmann> melwitt: yeah
16:29:59 <melwitt> and I agree if we were to change that behavior, would need a microversion and a spec I would think
16:30:16 <gmann> so it can lead to invalid projects be added in flavor access or valid one but users were not permission to GET /projects
16:30:42 <dansmith> are we going to allow them to opt-in to the old behavior though?
16:31:12 <gmann> dansmith: if they change the policy permission for user to allow GET /projects
16:31:33 <gmann> user still get the 200 and able to add project in flavor access
16:31:55 <dansmith> I'm just saying, I don't think we'd want a microversion for changing something like that unless we're going to allow them to use the old microversion to create the flavor without the checking
16:32:40 <melwitt> I'm not sure whether it makes sense to change it though, if the user doesn't have permission to check for project existence, what else can we do but just pass it? is the suggestion to use the admin context to check for project existence and have it no longer matter what the user permission is?
16:33:40 <dansmith> if the user doesn't have permission to GET the project, we should not create the thing anyway and just assume it's legit right?
16:33:42 <melwitt> I guess they are proposing to fail all requests that cannot verify the project
16:33:43 <gmann> melwitt: it is to fail when no permission for GET projects and ask admin to give permission first and then try
16:33:59 <gmann> melwitt: yes
16:34:33 <gmann> i am towards, microversion not needed but a deprecation warning for one cycle before we change it
16:35:14 <gmann> becasue admin needs to change their policy permission to keep it working as old behaviour. which is same as when we change the policy default permission
16:35:19 <gibi> gmann: when we will log the deprecation warning? for each request flavor access request where we get 403 from keystone ?
16:35:29 <gmann> gibi: yes
16:35:58 <gmann> and satying this behavious is going to change next cycle so fix your policy permission before we start failing it
16:36:03 <melwitt> don't most of the APIs verify project? then most of them will see requests start failing and then they have to add permission to GET /projects for anything to work? I guess I don't see why we wouldn't just elevate permission internally to check projects
16:36:43 <melwitt> like what if they don't want to give all their users admin to GET projects
16:36:59 <dansmith> they do that via the token though right?
16:37:02 <gmann> melwitt: if context project then fine which is all API but flavor access need other project to verify than one in context.
16:37:11 <dansmith> a user's token and project can be validated with the token, this is different
16:38:06 <gmann> https://review.opendev.org/#/c/735068/4/nova/api/openstack/identity.py@34
16:38:13 <gmann> yeah
16:38:16 <melwitt> I think I understand. just saying I think a lot of APIs do this, in an attempt to prevent users trying to take action against projects that don't exist
16:38:42 <dansmith> against _other_ projects?
16:38:59 <dansmith> quota is the only thing I can think of
16:39:06 <gmann> against_other_project is for flavor access and quota only i think
16:39:07 <melwitt> hm. yeah, I was thinking of quota too
16:39:49 <dansmith> just curious,
16:39:57 <dansmith> when you GET the project you can't see, do you get a 401 or 404?
16:40:00 <stephenfin> I'd crash and burn, personally
16:40:00 <gmann> becasue 403 from keystone does not guarantee that whether  projects is present or not
16:40:09 <gmann> dansmith: 403
16:40:17 <dansmith> 401 might be enough to tell us "it exists, but you can't see it" if they guarantee to keep that behavior
16:40:28 <dansmith> gmann: ack, same difference for 403
16:40:33 <stephenfin> You're effectively modifying this other project by allocating a flavor to it
16:40:40 <gmann> humm but project may not exist?
16:40:47 <dansmith> gmann: that should be 404 right?
16:41:10 <melwitt> stephenfin: I guess I could see that
16:41:11 <gmann> dansmith: but if permission is not allowed then keystone return only 403
16:41:19 <gmann> which mean project may or may not exist
16:41:25 <dansmith> stephenfin: yeah, that's a legit way to think about it.. could be costing that person money
16:41:33 <dansmith> gmann: okay that's what I was asking
16:41:51 <dansmith> I doubt anyone charges for flavors but they could
16:42:48 <gibi> I'm fine with a deprecation warning and then in W raise the keystone error back to the user
16:42:57 <dansmith> same
16:43:29 <gmann> at least with warning for cycle and then change can tell operators 'this user not having GET projects permission was adding projects to flavor so audit it and give permission accordingly'
16:43:42 <melwitt> and quotas
16:43:58 <melwitt> oh that's just an example
16:44:00 <stephenfin> That would suggest we're not backporting the fix though
16:44:32 <gmann> stephenfin: if we backport warning then we could but not sure.
16:45:16 <gmann> but not sure how backport work, at least we can fix W onwards.
16:45:20 <dansmith> I think we should not backport
16:45:24 <gmann> ok
16:45:25 <stephenfin> I assume we're not doing a microversion because of the "don't make users opt into non-broken behavior" guideline?
16:45:58 <dansmith> right
16:46:05 <gmann> yeah
16:46:08 <stephenfin> Aren't we effectively doing that a different way then by saying the fix will only be included in W?
16:46:22 <stephenfin> You can only opt-in to non-broken behavior by upgrading
16:46:22 <dansmith> no
16:46:42 <dansmith> nearly everything fits that description
16:47:50 <stephenfin> maybe, but then why not just do a microversion?
16:48:02 <stephenfin> that's how we communicate API behavior changes
16:48:12 <gibi> because then in W the user can still use the wrong behavior
16:48:20 <dansmith> because we're not going to let them opt-into the *broken* behavior either
16:48:23 <dansmith> right
16:49:46 <stephenfin> then fix it now, so they don't have to deal with the broken behavior now
16:50:09 <stephenfin> idk, this just feel really odd. I can't think of other cases where we've taken this path
16:50:09 <gibi> but they might have a broken config too
16:50:14 <dansmith> it's still a change and the warning is meaningful, IMHO
16:50:26 <gmann> stephenfin: at least warning give them time to fix which is permission fix only
16:50:49 <gmann> how we do policy default change.
16:51:23 <dansmith> nine minutes left and we're still on api subteam
16:51:29 <gmann> yeah,
16:51:48 <gmann> let' continue on nova affter meeting
16:51:52 * stephenfin will think on this more and leave notes on the review
16:51:53 <gibi> OK
16:51:59 <gibi> Libvirt (bauzas)
16:52:01 <gmann> stephenfin: +1, thanks
16:52:10 <bauzas> you lost me ;)
16:52:21 <bauzas> nothing to report here except I'm melting in my office
16:52:27 <bauzas> EOF.
16:52:42 <gibi> bauzas: I feel your pain
16:52:44 <gibi> #topic Stuck Reviews
16:52:51 <gibi> nothing on the agenda
16:53:04 <gibi> anybody has anything that is stuck?
16:53:37 <gibi> #topic Open discussion
16:53:46 <gibi> nothing on the agenda here either
16:54:29 <gibi> I guess we are done
16:54:40 * bauzas runs off for a beer
16:54:48 <gibi> bauzas: have a nice one
16:54:55 <gibi> thank you all for joining
16:55:04 <gibi> and happy 4th of July
16:55:09 <dansmith> \o/\
16:55:14 <gmann> thanks
16:55:27 <gibi> #endmeeting