| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-11-30 | |||
| 16:23:51 | dansmith | I am, if you have questions | |
| 16:24:09 | bauzas | honestly, I don't think I have any concerns | |
| 16:24:32 | dansmith | I've been working on a patch to get servers back to the place where we want it, | |
| 16:24:33 | bauzas | maybe one about upgrades and what it means for operators that were modifying the policies | |
| 16:24:35 | dansmith | as an example people can work from | |
| 16:24:39 | dansmith | and it's very close | |
| 16:24:51 | bauzas | but this is just changing the defaults | |
| 16:24:54 | dansmith | gmann and johnthetubaguy[m] are mostly happy I think, just working out one more functional thing | |
| 16:25:19 | dansmith | bauzas: well, this is pretty much all about defaults anyway, | |
| 16:25:34 | dansmith | and nobody could really have rolled to the new ones yet anyway, so not an upgrade concern, IMHO | |
| 16:25:46 | dansmith | but the revised plan involves less change when they do upgrade | |
| 16:26:31 | bauzas | dansmith: I guess you're referring to https://review.opendev.org/c/openstack/governance/+/815158/20/goals/proposed/consistent-and-secure-rbac.rst as the revised plan ? | |
| 16:26:40 | dansmith | yep | |
| 16:27:24 | bauzas | ok, | |
| 16:27:45 | bauzas | this plan isn't yet sold but whatever it will be, nothing will really change from nova | |
| 16:28:02 | dansmith | well, things have to change in nova of course, | |
| 16:28:08 | bauzas | so as you said, I don't think there is any upgrade concern then | |
| 16:28:29 | bauzas | nothing will really change from a nova perspective if you prefer | |
| 16:28:37 | dansmith | but mostly just undoing some of the proposed stuff that hasn't been able to be realized yet.. stepping back from some of that stuff that we merged proactively | |
| 16:28:40 | bauzas | things have to change, but upgrades aren't a concern either way | |
| 16:29:00 | dansmith | much less of a concern than what they were, but of the stuff we're keeping, no real change, yeah | |
| 16:29:24 | dansmith | and keystone will go first which will help our upgrade be even less impactful than it was going to be, if we ever got past the big bubble we had going | |
| 16:29:48 | bauzas | to answer the original paperwork question, I think there is no controversy to tell it's a specless BP and we don't to document this as we already have https://review.opendev.org/c/openstack/governance/+/815158/20/goals/proposed/consistent-and-secure-rbac.rst | |
| 16:30:02 | bauzas | we don't need* to | |
| 16:30:13 | dansmith | ++ | |
| 16:30:44 | bauzas | that said, of course this work will need some release notes | |
| 16:30:54 | dansmith | obviously | |
| 16:30:55 | bauzas | to explain the changes to the operators | |
| 16:31:00 | bauzas | ok | |
| 16:31:04 | bauzas | anyone has other concerns N? | |
| 16:31:22 | bauzas | dang, I need to learn typing | |
| 16:31:58 | bauzas | (and that's what happens when you have a french keyboard with ? located near n and requiring shift) | |
| 16:32:08 | bauzas | anyway | |
| 16:32:41 | bauzas | #agreed https://blueprints.launchpad.net/nova/+spec/policy-defaults-refresh-2 accepted as a specless BP as the direction is already explained in https://review.opendev.org/c/openstack/governance/+/815158/ | |
| 16:32:50 | bauzas | moving on, last topic | |
| 16:33:12 | bauzas | (ganso) Raising awareness of vif_multiqueue_enabled in flavor work that is ready to be reviewed/merged | |
| 16:33:15 | bauzas | ganso: around ? | |
| 16:33:21 | ganso | o/ | |
| 16:33:34 | bauzas | #link https://blueprints.launchpad.net/nova/+spec/multiqueue-flavor-extra-spec | |
| 16:33:49 | ganso | so as the topic titles says: https://review.opendev.org/q/topic:%22bp%252Fmultiqueue-flavor-extra-spec%22+(status:open%20OR%20status:merged) | |
| 16:34:14 | ganso | we've discussed 2-3 weeks ago about this and that it could/may be specless, but it was approved to be specless ~6 months ago | |
| 16:34:20 | bauzas | ganso: nothing changed during the implementation phase requiring further discussion ? | |
| 16:34:45 | ganso | bauzas: as far as I know, nothing changed and the code is complete | |
| 16:35:05 | bauzas | the BP was previously approved as specless so I don't see problems approving it again providing there were no changes in design | |
| 16:35:08 | ganso | I rebased it and it is passing CI | |
| 16:35:13 | bauzas | (requiring further discussions) | |
| 16:36:11 | ganso | I'm pretty much shepherding this set of changes now, but the work was done by stephenfin | |
| 16:36:12 | bauzas | ganso: I guess you're taking over stephenfin's work ? | |
| 16:36:22 | ganso | yes | |
| 16:36:25 | bauzas | OK, that's crystal clear then | |
| 16:36:39 | bauzas | I don't have any problems reapproving it | |
| 16:36:49 | bauzas | anyone else disagreeing ? | |
| 16:36:49 | ganso | great =) | |
| 16:37:28 | bauzas | #agreed https://blueprints.launchpad.net/nova/+spec/multiqueue-flavor-extra-spec to approve it again as a specless BP for the yoga release cycle | |
| 16:37:50 | bauzas | we're at the end of the agenda, anything else to mention ? | |
| 16:38:15 | bauzas | I'm happy to say we were quick this time :) | |
| 16:38:24 | gibi | \o/ | |
| 16:38:30 | bauzas | if not, | |
| 16:38:34 | bauzas | #endmeeting* | |
| 16:38:34 | opendevmeet | Meeting ended Tue Nov 30 16:38:34 2021 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | |
| 16:38:34 | opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2021/nova.2021-11-30-16.00.html | |
| 16:38:34 | opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2021/nova.2021-11-30-16.00.txt | |
| 16:38:34 | opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2021/nova.2021-11-30-16.00.log.html | |
| 16:38:49 | bauzas | man, I'm fed up with my typing issues | |
| 16:40:03 | bauzas | thanks all | |
| 16:40:22 | elodilles | thanks bauzas o/ | |
| 16:40:57 | bauzas | I'm a gross person, I haven't officially thanked you all at the end of the meeting | |
| 16:42:09 | elodilles | :D | |
| 17:07:13 | bauzas | gmann: can I put you assignee on https://blueprints.launchpad.net/nova/+spec/policy-defaults-refresh-2 ? | |
| 17:14:48 | opendevreview | Nicolas Parquet proposed openstack/nova master: Add v2.91 microversion, allowing @ and dot (.) characters in keypair name https://review.opendev.org/c/openstack/nova/+/781076 | |
| 18:05:52 | gmann | bauzas: sure, thanks | |
| 18:07:59 | opendevreview | Dan Smith proposed openstack/nova master: Revert project-specific APIs for servers https://review.opendev.org/c/openstack/nova/+/816206 | |
| 18:08:00 | opendevreview | Dan Smith proposed openstack/nova master: Make API fixture pass roles https://review.opendev.org/c/openstack/nova/+/819907 | |
| 18:08:26 | dansmith | gmann: this has the fixture change on top ^ so you can see it not working without it, and then working when we change that | |
| 18:08:42 | dansmith | I haven't done more digging on why this is required, but hoping it's something you can spot easily | |
| 18:08:53 | gmann | dansmith: ok, checking | |
| 18:08:54 | dansmith | I wonder if we're not really testing fake policy like we think in functional? | |
| 18:09:47 | gmann | dansmith: which is good :). I wanted to remove those fake policy from unit as well as from functional tests completely but that might need more tests modification but something we should do. | |
| 18:10:29 | dansmith | don't disagree that it would be better, I just don't know why this is required right now, | |
| 18:10:40 | dansmith | since I would expect us to at most be testing with old defaults OR'd in | |
| 18:11:13 | gmann | sure, I will check it where we are missing things. | |
| 18:11:46 | gmann | dansmith: did you see my comment https://review.opendev.org/c/openstack/nova/+/816206/9/nova/policies/base.py | |
| 18:12:12 | gmann | dansmith: if CONTEXT_ADMIN if more readable then it is fine otherwise we can ad ADMIN ? | |
| 18:12:27 | dansmith | gmann: oh yeah I did, I just got distracted by the functional failures | |
| 18:12:59 | gmann | I started converting SYSTEM_READER to SYSTEM_ADMIN on top of your patch so doing it in base patch will avoid rebase or so | |
| 18:13:00 | gmann | sure | |
| 18:57:52 | gmann | dansmith: this is reason for functional test failure https://review.opendev.org/c/openstack/nova/+/816206/comment/510a59e0_5ffbc2f5/ | |
| 18:58:12 | gmann | dansmith: functional test using the real policy helped us to capture it. | |
| 19:00:04 | dansmith | gmann: ahh, I was probably conflating that rule with the admin_or_owner below it when thinking that we'd still have the old default | |
| 19:01:40 | gmann | dansmith: yeah, and those role hierarchy fix in 819907 made test passing because of 'admin' being used as user-id for functional test https://review.opendev.org/c/openstack/nova/+/819907/comment/eba56840_d585da0a/ | |
| 19:02:17 | dansmith | gmann: you mean that's why they worked before I switched the rule... | |
| 19:03:14 | dansmith | gmann: should I use admin_or_owner for those flavor-extra-spec rules, or add the DEPRECATED_ADMIN_OR_OWNER to context_admin/ | |
| 19:05:22 | gmann | dansmith: I think DEPRECATED_ADMIN_POLICY as CONTEXT_ADMIN is going to replace SYSTEM_ADMIN only . I was trying to do it this way https://review.opendev.org/c/openstack/nova/+/819389 | |
| 19:06:07 | gmann | and PROJECT_ADMIN going to be with DEPRECATED_ADMIN_OR_OWNER which has project_id in that | |
| 19:08:22 | gmann | dansmith: let me update my patch and then you can use the new ADMIN rule for place of role:admin | |
| 19:08:56 | dansmith | gmann: ack | |
| 19:09:06 | dansmith | gmann: we still want my patch to pass proper roles from the fixture though right? | |
| 19:09:32 | dansmith | presumably we need to also let you get a fixture with no (or foo) roles for testing that member is enforced | |
| 19:14:38 | gmann | dansmith: for is_admin L1092 yeah it is ok but else part make reader also give member authority https://review.opendev.org/c/openstack/nova/+/819907/1/nova/tests/fixtures/nova.py#1092 | |
| 19:15:22 | gmann | if we remove the else part and let real role being tested what test use then it should be ok | |