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