16:00:12 <bauzas> #startmeeting nova
16:00:12 <opendevmeet> Meeting started Tue Jan 10 16:00:12 2023 UTC and is due to finish in 60 minutes.  The chair is bauzas. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:12 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:12 <opendevmeet> The meeting name has been set to 'nova'
16:00:21 <bauzas> #link https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting
16:00:45 <bauzas> good UTC afternoon everyone
16:00:48 <bauzas> who's around ?
16:00:49 <dansmith> Oj
16:00:51 <gibi> o/
16:00:53 <gmann> o/
16:00:58 <kgube> o/
16:01:05 <elodilles> o/
16:01:17 <sean-k-mooney> o/
16:01:18 <Uggla> o/
16:01:26 <Kirill_> o/
16:01:29 <bauzas> welcome everyone
16:01:48 <bauzas> #topic Bugs (stuck/critical)
16:01:53 <bauzas> #info No Critical bug
16:01:57 <bauzas> #link https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New 27 new untriaged bugs (+2 since the last meeting)
16:02:02 <bauzas> I have to do my duty
16:02:27 <bauzas> if someone has time for triaging upstream bugs, that'd be lovely but I can do it
16:02:35 <bauzas> and then we'll go back to the roster
16:02:41 <bauzas> #info Add yourself in the team bug roster if you want to help https://etherpad.opendev.org/p/nova-bug-triage-roster
16:03:22 <Uggla> bauzas, bug triage, I can do it is it helps you.
16:03:27 <gibi> +1 for the roster
16:03:51 <bauzas> Uggla: I'll take the baton for this week, but if you want, we can both look at bugs
16:04:07 <bauzas> #info bug baton is being passed to bauzas
16:04:29 <bauzas> any particular urgent bug to discuss ?
16:04:40 <bauzas> I guess we'll discuss the tox saga in the next chapter
16:04:59 <bauzas> if no, let's move on and go to the gate topic
16:05:06 <bauzas> #topic Gate status
16:05:12 <bauzas> #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs
16:05:16 <bauzas> #link https://zuul.openstack.org/builds?project=openstack%2Fnova&project=openstack%2Fplacement&pipeline=periodic-weekly Nova&Placement periodic jobs status
16:05:21 <bauzas> #link https://review.opendev.org/c/openstack/tempest/+/866049 proposal to add more delay for centos9s-fips job
16:05:26 <bauzas> #info Please look at the gate failures and file a bug report with the gate-failure tag.
16:05:30 <gibi> placement and nova gate is unblocked as far as I know. we merged the two tox4 patches
16:05:31 <bauzas> #info STOP DOING BLIND RECHECKS aka. 'recheck' https://docs.openstack.org/project-team-guide/testing.html#how-to-handle-test-failures
16:05:51 <bauzas> I was about to tell it once I was done with the weekly items
16:05:52 <bauzas> so,
16:06:12 <gibi> I see nova patches progressing in the gate queue
16:06:17 <gibi> so I think we are OK
16:06:33 <gibi> I haven't chacked osc-placement and python-novaclient status
16:06:40 <gibi> os-vif should be unblocked too
16:06:46 <gmann> their master gate is good, I checked
16:06:54 <gmann> but for stable branch gate, python-novaclient patches need to merge #link https://review.opendev.org/q/I442568a5f5900e593feb2b5527109e0aa79e5aa7+status:open
16:07:12 <dansmith> nice
16:07:15 <gmann> and osc-placement is failing <= stable/yoga https://review.opendev.org/c/openstack/osc-placement/+/869451
16:07:17 <bauzas> #info we had a funky week due to tox4 but now gate is better https://lists.openstack.org/pipermail/openstack-discuss/2023-January/031709.html
16:07:41 <gmann> it is failing on placement functionla job where we use master placement but stable branch constraints so mismatch
16:07:42 <bauzas> gmann: cool, I'll look at the novaclient patch
16:08:11 <gmann> I cannot remember why we do not use master constraints in that placement functional job?
16:08:12 <bauzas> oh, I did it already
16:08:13 <gibi> the there are follow up request for nova and placement too: i) remove the install_command usage ii) check if pdf doc build works or not
16:08:33 <gibi> gmann: we should I believe
16:08:43 <gmann> this one https://github.com/openstack/osc-placement/blob/master/tox.ini#L30
16:09:26 <sean-k-mooney> we want it t o run against master i belvie
16:09:28 <gibi> gmann: hm, do we have placement in the upper-constraints?
16:09:43 <sean-k-mooney> perhaps although we shoudl not
16:09:54 <sean-k-mooney> only lib projects should eb in uc
16:09:57 <gmann> gibi: no because we use it from master source
16:10:12 <bauzas> sean-k-mooney: this is for testing placement itself
16:10:22 <bauzas> so we need the latest
16:10:22 <gibi> this is testing osc-placement I believe
16:10:32 <bauzas> correct
16:10:36 <gmann> yeah testing osc-placement with master placement
16:10:42 <sean-k-mooney> its the fucntional test for placement openstackclient plugin
16:10:45 <gibi> and constarints are inherited from https://github.com/openstack/osc-placement/blob/fdf10423bf29b7cfd5e88d9d06e1313ee881ab80/tox.ini#L17
16:10:48 <bauzas> we're discussing of testing osc-placement
16:10:59 <bauzas> using placement master branch
16:11:07 <sean-k-mooney> yes and how the functional job forces the master branch of placment
16:11:14 <bauzas> yup
16:11:18 <sean-k-mooney> i think this was because fo the placment fixture
16:11:18 <gmann> gibi: it use stable/yoga for yoga testing #link https://github.com/openstack/osc-placement/blob/stable/yoga/tox.ini#L18
16:11:23 <gmann> for master it is all good
16:11:28 <gmann> master gate
16:11:33 <bauzas> agreed with gmann
16:11:34 <sean-k-mooney> https://github.com/openstack/osc-placement/commit/da8cd4d68b06399c607776db2a704b4578146996
16:11:45 <gibi> I don't see the issue sorry
16:11:54 <gmann> for stable/zed somehow constraints matches so we do not see failure
16:11:55 <bauzas> if I have a osc client patch, I don't wanna hold my check on a placement release
16:11:55 <sean-k-mooney> so the tox.ini is correct
16:12:25 <gmann> sean-k-mooney: stable/yoga constraints will not work with latest placement
16:12:39 <bauzas> anyway, tox4 upgrade was fun
16:12:45 <gmann> that is why it is failing on os-traits version mismatch
16:13:02 <sean-k-mooney> for stable branchs we likely need to pin yes
16:13:05 * bauzas wonders whether pyproject.toml files were having the same issues than tox.ini
16:13:26 <gmann> yeah, either pin placement or use master constraints for this latest placement testing
16:13:27 <sean-k-mooney> bauzas: likely not because they handel constratits differnrlty
16:13:42 <gmann> anyways we can discuss it after meeting as it seems need more discussions
16:13:43 <gibi> gmann: so on stable/yoga this is an issue https://github.com/openstack/osc-placement/blob/stable/yoga/tox.ini#L31
16:13:57 <gibi> as it install master placement on stable yoga
16:14:09 <gmann> gibi: yes.
16:14:11 <sean-k-mooney> ya so we just need to pin the branch in that line which is posible
16:14:14 <gibi> OK I got it
16:14:21 <elodilles> as i remember constraints from master also caused issues on stable branches (in placement)
16:14:30 <bauzas> sean-k-mooney: yeah, my point is that if the tox developers don't verify the behaviours of tox.ini and rather say they just verify the toml ones, then I'm a bit afraid
16:14:47 <sean-k-mooney> bauzas: its not related to that
16:15:14 <sean-k-mooney> bauzas: openstack is quite differnt form ontehr python project in how we use setuptools/pbr and the idea of a constratis file
16:15:23 <gmann> all other stable branches gate are good. I tested them after pin
16:15:32 <gibi> bauzas: tox4 was a rewrite, and they are not intending to keep all the tox3 behavior (I learned yesterday)
16:15:43 <bauzas> sean-k-mooney: sure I'm not saying we should create a pyproject.toml filze
16:15:50 <gibi> gmann: thanks!
16:16:06 <bauzas> sean-k-mooney: but I was wondering why nobody was finding the problem until we told them
16:16:08 <sean-k-mooney> bauzas: well that has been discussed and we might want to eventually but we should lop back to one topic
16:16:25 <sean-k-mooney> bauzas: because constrait files is baicaly an openstack thing
16:16:44 <bauzas> sean-k-mooney: we didn't had only problems with constraints
16:16:45 <clarkb> sean-k-mooney: openstack is the primary user in the wild probably but it is a normal pip functionality
16:16:53 <sean-k-mooney> we are the comunity that drove that in pip
16:17:10 <sean-k-mooney> but yes its is a pip capablity
16:17:11 <bauzas> gibi: ack, good to know
16:17:14 <clarkb> bauzas: fwiw I'm helping to move zuul and opendev projects to nox
16:17:29 * bauzas notes it
16:17:33 <sean-k-mooney> isnit that a pti issue
16:17:41 <sean-k-mooney> dont we specify tox explictly
16:17:43 <clarkb> (because there are lots of little tox changes and when I file issues upstream the resposne is often "why would you do that?" and the answer is well because v3 supported it so ya...)
16:17:51 <clarkb> sean-k-mooney: yes for openstack. I personally think openstack should change too
16:17:56 <clarkb> but it is work
16:18:03 <sean-k-mooney> perhaps a good ptg topic
16:18:10 <gmann> +1
16:18:12 <dansmith> I'm not super keen on the nox thing
16:18:13 <sean-k-mooney> how to evovle pti
16:18:14 <bauzas> not only for our project
16:18:21 <dansmith> so I'd like to have a real discussion about it
16:18:33 <bauzas> should be a cross-project discussion honestly
16:18:34 <dansmith> (I'm also not super keen on tox destroying the world for fun and profit)
16:18:37 <sean-k-mooney> right i was thinking comuity/cross project topic
16:18:45 <bauzas> dansmith: me too
16:18:50 <gmann> right
16:19:11 <bauzas> honestly, I'd have preferred to continue using tox3 until we test all the modifications they did
16:19:11 <sean-k-mooney> ok so looping back. we need to pin placment on stable branches fo osc-placment
16:19:19 <bauzas> but, this is done
16:19:30 <sean-k-mooney> and we have unbolcked the other "nova" gates
16:19:42 <sean-k-mooney> with followups for the install_commands changes correct?
16:19:54 <gmann> sean-k-mooney: gibi: ok for pin but I was thinking we have to test latest placement there? I do not know reason just want to confirm
16:20:21 <sean-k-mooney> gmann: git+https://opendev.org/openstack/placement.git#egg=openstack-placement line on master
16:20:27 <sean-k-mooney> is so we get the latest placement fixture
16:20:32 <bauzas> and the fact that tox developers just rewrite their tox.ini by what they want without continuing to support the existing (and without deprecating them at least) let me think about any new major tox versions we'd have
16:20:38 <gmann> so we need to test latest placement in master gate only
16:20:38 <gibi> gmann: I don't know the reason either
16:20:38 <sean-k-mooney> so we can test when new feture are addded
16:21:17 <gmann> sean-k-mooney: right but that we do not need on stable osc-placement version right?
16:21:41 <sean-k-mooney> gmann: correct it can and should use the stable version
16:21:52 <gmann> I was hesitating to pin placement there as I do not know the original reason ot use latest placement there
16:21:54 <sean-k-mooney> they do need to be kept in sync however
16:22:06 <sean-k-mooney> its caputed in teh comme messange here https://github.com/openstack/osc-placement/commit/da8cd4d68b06399c607776db2a704b4578146996
16:22:18 <gmann> ack
16:22:48 <gmann> thanks
16:24:33 <sean-k-mooney> ok i think we have covered those topics and can move on
16:24:42 <bauzas> I was about to ask
16:24:49 <bauzas> ok, let's move on then
16:24:54 <gmann> yeah
16:25:00 <bauzas> #topic Release Planning
16:25:04 <bauzas> #link https://releases.openstack.org/antelope/schedule.html
16:25:07 <bauzas> #info Antelope-3 is in 5 weeks
16:25:16 <bauzas> (and featurefreeze... :) )
16:25:21 <bauzas> #info As a reminder, Nova SpecFreeze deadline is this Thursday https://lists.openstack.org/pipermail/openstack-discuss/2023-January/031636.html
16:26:08 <bauzas> I'll modify launchpad's https://blueprints.launchpad.net/nova/antelope once we're done with reviewing specs
16:26:58 <bauzas> I have then a question
16:27:07 <bauzas> #link https://lists.openstack.org/pipermail/openstack-discuss/2023-January/031645.html I guess we'll want to have a virtual PTG again ?
16:27:39 <bauzas> for the Bobcat planning :)
16:27:55 <bauzas> (man, haven't but should have voted this time...)
16:28:02 <sean-k-mooney> can we create teh 2023.2 specs repo after spec freeze
16:28:19 <sean-k-mooney> i dont recall seeing a vote email go out
16:28:24 <bauzas> there was one
16:28:28 <sean-k-mooney> i tought this was selected by the foundation
16:28:51 <bauzas> nope, sent during your holidaus
16:28:56 <sean-k-mooney> ok well the foundation has never consicidently sent me vote urls anyway
16:28:58 <bauzas> hence why you haven't probably seen it
16:29:01 <gmann> format will be 1 virtual PTG + 1 in-person PTG per year. in-person PTG will be aligned to summit+release
16:29:36 <bauzas> gmann: any chance to have those physical attendances (I don't like the PTG naming) to be at the start of the release time ?
16:29:47 <bauzas> for Vancouver, ship is sailed
16:30:25 <dansmith> sean-k-mooney: I didn't get one either
16:30:50 <gmann> bauzas: yeah, that is what foundation staff updated that they will try to aligned it with summit and openstack relaese but let's see as it can be challenging too
16:30:52 <bauzas> dansmith: sean-k-mooney: https://lists.openstack.org/pipermail/openstack-discuss/2022-December/031551.html
16:31:10 <dansmith> oh, to the list
16:31:19 <bauzas> 70% of the list was probably on PTO
16:31:24 <sean-k-mooney> but that vote url is a personal one
16:31:28 <sean-k-mooney> not one everyone can use right
16:31:33 <gmann> for vancouver, yes as event is in between of cycle it needs to be that time
16:31:44 <sean-k-mooney> you are ment to get one to your personal email for all votes
16:31:56 <bauzas> sean-k-mooney: good point, again, I haven't voted so I haven't tested it
16:32:31 <gmann> sean-k-mooney: I think it is public vote so anyone can vote with that url but one per IP or so
16:32:37 <bauzas> anyway, this is done anyway
16:32:42 <gmann> if I am remembering public vote things correctly
16:32:46 <bauzas> gmann: fun fact is, voting isn't closed AFAICS
16:33:02 <sean-k-mooney> perhaps in the tool but the name has been released
16:33:14 <bauzas> yup, another ship sailed
16:33:18 <sean-k-mooney> in anycase i can create a 2023.2 folder in the spec repo
16:33:20 <gmann> ohk :) honestly saying I have not given mush attention to release naming :)
16:33:28 <gmann> sean-k-mooney: +1
16:33:33 <bauzas> sean-k-mooney: wait for the spec freeze
16:33:41 <sean-k-mooney> but bauzas  if you want to do that after spec freeze we can wait till after thrsday
16:33:41 <opendevreview> Merged openstack/nova stable/wallaby: Adapt websocketproxy tests for SimpleHTTPServer fix  https://review.opendev.org/c/openstack/nova/+/866194
16:33:42 <bauzas> sean-k-mooney: or it would perhaps confuse people
16:33:53 <bauzas> sean-k-mooney: well, I'm not opposed to delegate
16:34:07 <sean-k-mooney> cool well i ahve done it in the past but lest do it next week
16:34:44 <bauzas> anyway, I guess we vote for a virtual PTG on end of  March ? (that was the original question)
16:35:20 <bauzas> and we don't say "meh, no, just let's do a physical one at right the middle of the release, and go f*** our deadlines !"
16:35:22 <bauzas> :D
16:36:16 <bauzas> I hear crickets, so I decide so
16:36:19 <elodilles> well, that is the usual PTG time, so i think it is not something to vote for :)
16:36:23 <gmann> not sure physical one can be utilized same as our normal PTG but can plan for some operaotr oriented discussions
16:36:41 <bauzas> #info we'll have a virtual Nova PTG on March 27-31
16:36:45 <gmann> virtual one in March will be the normal vPTG we have for cycle
16:36:48 <bauzas> I'll register our name :)
16:37:08 <bauzas> gmann: honestly, I don't expect much more from what we currently have at the Forum
16:37:13 <bauzas> gmann: but let's be creative
16:37:17 <gmann> bauzas: yeah.
16:37:42 <bauzas> if we really need to s/Forum/PTG to have more people coming, I'm not opposed to a rebranding
16:37:53 <elodilles> some teams do mid-cycle PTG-s, so the in-person one can be considered such, i guess
16:37:56 <gmann> we asked same PTG fomat questions on vancouver PTG but that is not answer yet
16:38:23 <bauzas> elodilles: given the Summit will be around Spec Freeze, that's gonna be fun
16:38:27 <gmann> I think in openstack-discuss ML but anyways let's see
16:38:50 <bauzas> elodilles: but we could do 'review sprints' or 'implementation sessions'
16:39:03 <bauzas> if that helps people wanting to come :)
16:39:10 <gmann> +1. good idea
16:39:16 <bauzas> I guess we're done on that topic
16:39:31 <bauzas> moving on
16:39:36 <bauzas> #topic Review priorities
16:39:44 <bauzas> #link https://review.opendev.org/q/status:open+(project:openstack/nova+OR+project:openstack/placement+OR+project:openstack/os-traits+OR+project:openstack/os-resource-classes+OR+project:openstack/os-vif+OR+project:openstack/python-novaclient+OR+project:openstack/osc-placement)+(label:Review-Priority%252B1+OR+label:Review-Priority%252B2)
16:39:50 <bauzas> #info As a reminder, cores eager to review changes can +1 to indicate their interest, +2 for committing to the review
16:40:13 <bauzas> I'll slowly but progressively use this label for knowing what to review
16:40:17 <bauzas> so you know about it
16:40:25 <bauzas> next topic (we only have 20 mins)
16:40:29 <bauzas> #topic Stable Branches
16:40:34 <bauzas> elodilles: happy to see you back
16:40:41 <elodilles> :)
16:40:49 <elodilles> we mostly discussed, but
16:41:10 <elodilles> #info stable branches seem to be unblocked / OK -- except placement, osc-placement, ...
16:41:33 <elodilles> thanks gmann for fixing the tox4 issues on stable branches!
16:41:45 <elodilles> #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci
16:41:54 <elodilles> and maybe one more thing:
16:41:55 <gmann> for pin not fix :)
16:42:13 <elodilles> gmann: yepp, a good workaround for now ;)
16:42:53 <elodilles> so maybe we should do nova stable releases as there are already some merged content on zed, yoga and xena
16:43:29 <elodilles> and a small side track: i would want some stable core opinions about my comment here: https://review.opendev.org/c/openstack/nova/+/867912
16:43:46 <elodilles> as the zed release might depend on that
16:43:53 <bauzas> elodilles: sure, want me to create the releases ?
16:44:01 <bauzas> stable releases, I mean
16:44:04 <elodilles> but that can be done after the meeting
16:44:08 <bauzas> we're in a good timing
16:44:45 <sean-k-mooney> elodilles  this is your main question right https://review.opendev.org/c/openstack/nova/+/867912/5/nova/conf/workarounds.py
16:44:49 <elodilles> bauzas: yes, if you have time :) otherwise i can also propose them
16:44:57 <elodilles> sean-k-mooney: yes
16:45:06 <sean-k-mooney> so i considerd that when reviewing
16:45:25 <sean-k-mooney> i tought the value of the fix in behaivor outwaied the possibel performance impact
16:45:44 <sean-k-mooney> but you are correct that fliping the default would maintain the old behaivor
16:46:01 <sean-k-mooney> fliping the default woudl also result in a workaorunds option being enabeld by default
16:46:07 <sean-k-mooney> which we generally avoid
16:46:20 <sean-k-mooney> so not changing the default felt more consitent to me
16:46:41 <sean-k-mooney> im not sure what other think ^
16:46:47 <bauzas> hmmm
16:46:52 <bauzas> loading the context
16:47:20 <sean-k-mooney> the context is mostly captured in teh help text :)
16:47:21 <bauzas> so it was a opt-out config
16:47:36 <bauzas> and when backporting it suddently became opt-in
16:47:44 <bauzas> right?
16:47:49 <sean-k-mooney> no we did not change it when back porting
16:47:55 <sean-k-mooney> elodilles: question is should we
16:48:14 <sean-k-mooney> so on master we default to the new more desireable beahvior
16:48:15 <elodilles> no. to put it simple: we change the default behavior on stable branches
16:48:30 <sean-k-mooney> and elodilles  is asking shoudl we keep the old beahivor in the backports
16:48:36 <bauzas> https://review.opendev.org/c/openstack/nova/+/864773/3/nova/conf/workarounds.py default on master is False
16:48:40 <bauzas> so that's opt-in
16:49:00 <bauzas> which is the same for the backports
16:49:02 <elodilles> i mean, given an installed environment, they upgrade, and the behaviour is changed with the upgraded nova
16:49:14 <sean-k-mooney> elodilles: correct
16:49:18 <bauzas> elodilles: I don't see a problem here with keeping it opt-in
16:49:41 <sean-k-mooney> bauzas: well it will required all operator to update there config to adress the bug
16:49:57 <elodilles> bauzas: it is opt-out :) you have to change the configuration to have the existing behaviour
16:50:10 <bauzas> sean-k-mooney which is the current behaviour on master, right?
16:50:32 <sean-k-mooney> on master we now set the reseved value on instnace boot
16:50:51 <sean-k-mooney> before this patch we set reserved wehn deleteing
16:51:12 <bauzas> because the option defaults to False, right?
16:51:28 <bauzas> if you set to True, you keep the original behaviou
16:51:29 <sean-k-mooney> the workaroudn option is a skip to opt out yes and it default to false
16:51:31 <bauzas> behaviour
16:51:35 <sean-k-mooney> correct
16:51:43 <bauzas> ok
16:51:48 <bauzas> so, say we backport this
16:51:54 <bauzas> as it is
16:52:22 <bauzas> to understand, that means we'll change the behaviour by upgrading to the latest (obviously .y) release
16:52:26 <sean-k-mooney> as is then the stable branchs get the new behaivor and you need to modify the config to restore the old behaiovr
16:52:44 <sean-k-mooney> but this is an internal implemation detail that is not part of any public contract
16:52:47 <bauzas> I think we have semver for communicating the behavioural change
16:52:49 <sean-k-mooney> so we felt this was better
16:53:29 <bauzas> can we discuss this out of the meeting ?
16:53:33 <bauzas> we have 5 mins left
16:53:35 <sean-k-mooney> sure
16:53:42 <bauzas> #topic Open discussion
16:53:46 <bauzas> (bauzas) As a reminder, Summit proposals deadline is today 11:59pm PT
16:53:57 <elodilles> so if we release now zed, then the operators who uses zed, need to update their configs to have NOT to change how nova works
16:53:59 <bauzas> you have the very last minute to add your topics
16:54:26 <bauzas> fwiw, I proposed two forum sessions about nova onboarding and operator meet&greet
16:54:41 <bauzas> if someone wants to co-host the onboarding forum session, let me know
16:55:19 <bauzas> gmann: correct me but forum proposal deadline is on april ?
16:55:37 <bauzas> I'm confused by the fact they added the forum proposals in the tool
16:55:42 <gmann> bauzas: I hope so. I asked Erin in email but no reply yet. But from form it shows april
16:55:54 <bauzas> yup, hence my confusion
16:56:31 <bauzas> I just hope we won't get like Berlin some Forum sessions that very look like Summit sessions with slides and one-sided discussions
16:56:31 <kashyap> Oh, come on...after all the jobs passed, one "tempest-integrated-compute" job times out :( https://zuul.opendev.org/t/openstack/build/8b07fa0b71c94fb6abb2b350c5c84c74
16:56:44 <bauzas> kashyap: on our meeting atm
16:56:45 <kashyap> Oops, sorry for that random chime in.
16:56:52 <kashyap> bauzas: Yeah, only realized it just now (sorry)
16:56:56 <bauzas> np
16:57:00 <bauzas> (gmann) updates on switching the RBAC(scope and new defaults) defaults in nova
16:57:08 <gibi> bauzas: if you need a co-host for the onboarding then you can write me up
16:57:09 <bauzas> you have 3 mins
16:57:36 <bauzas> gibi: noted. I'm used to do some onboarding and I have ideas but having a co-speaker is somehow better
16:57:44 <gibi> sure
16:58:07 <bauzas> looks like gmann is gone and our meeting will end
16:58:14 <gmann> patch is ready for review #link https://review.opendev.org/c/openstack/nova/+/866218/12
16:58:19 <bauzas> cool thanks
16:58:40 <bauzas> gmann: I've seen your ping, I just didn't had time to review it yet
16:58:44 <gmann> please check and it need placement test fixture change too which is depends-on on nova change #link https://review.opendev.org/c/openstack/placement/+/869525/3
16:59:05 <gmann> do not want to delay the switching at the end of cycle
16:59:32 <bauzas> I've just said review-prio +2
16:59:44 <gmann> Tempest already run integration job with new RBAC on Nova, glance, neutron and cinder and it is passing finw
16:59:48 <gmann> thanks
16:59:51 <bauzas> \o/
17:00:03 <opendevreview> Pavlo Shchelokovskyy proposed openstack/nova master: Process all nodes when host aggregate changes  https://review.opendev.org/c/openstack/nova/+/869687
17:00:15 <bauzas> ok, we're on time
17:00:16 <bauzas> thanks all
17:00:20 <bauzas> #endmeeting