Earlier  
Posted Nick Remark
#openstack-nova - 2023-02-28
09:14:20 gibi the ptl guide has the timeline so I guess that is a good place to document the pattern to follow
09:14:41 bauzas oh yeah
09:14:50 bauzas I used it a lot
09:14:59 bauzas + the rc1 etherpads
09:15:26 bauzas I'll do a bit of scrubbing
09:26:50 opendevreview Sylvain Bauza proposed openstack/nova master: DNM (yet) Update min support for Bobcat https://review.opendev.org/c/openstack/nova/+/875621
09:28:36 sean-k-mooney bauzas: we do not need a skip level upgrade job for 2023.2
09:29:07 bauzas yet again a violent agreement ? :)
09:29:24 bauzas sean-k-mooney: see my latest rev of https://review.opendev.org/c/openstack/nova/+/875621
09:29:38 sean-k-mooney i was just reading that but i dont think we need it in the periodic
09:30:03 bauzas sean-k-mooney: I'll wait for dansmith's insights on it
09:30:17 bauzas if he's OK with only experimental, I'm fine.
09:30:39 sean-k-mooney it technically does not need to be there either but sure
09:30:42 bauzas but I'd somehow like the idea of having a periodic for ensuring we don't regress
09:30:47 sean-k-mooney there are no skip level upgrades to bobcat
09:31:03 bauzas I know
09:31:05 bauzas :)
09:31:12 sean-k-mooney cool
09:31:19 bauzas (well, I loaded again the context in my mind, I dare say)
09:31:21 sean-k-mooney so that job bascially is only needed half the year
09:31:35 bauzas well, we had it during the whole zed cycle too :)
09:32:07 bauzas my biggest concern that I raised to gibi is that it takes me always a lot of time to load again the context
09:32:15 bauzas so I want to eventually write docs about it
09:32:16 sean-k-mooney i think that was because that is when it was written
09:32:39 sean-k-mooney but sure it should proably get listed in the ptl guide or something like that
09:32:58 bauzas yup, scroll it up
09:33:02 bauzas I'm on it
09:33:03 gibi :)
09:33:15 bauzas https://review.opendev.org/c/openstack/nova/+/831229 was when we added the job
09:33:25 bauzas it was on the yoga timeframe
09:33:27 bauzas and then we left it
09:41:09 sean-k-mooney i see what release was it upgrading form during zed
09:41:17 bauzas gibi: sean-k-mooney: do you remember how we tracked the default policy changes from gmann ? It isn't a blueprint AFAICS
09:41:35 sean-k-mooney bauzas: its a blueprint/spec
09:41:46 bauzas I'm maybe blind
09:42:17 sean-k-mooney well
09:42:20 bauzas sean-k-mooney: I'm not talking of https://blueprints.launchpad.net/nova/+spec/policy-service-role-default
09:42:22 sean-k-mooney ok so the service role was
09:42:38 sean-k-mooney ya i asked for both to be blueprint/specs
09:42:51 sean-k-mooney because i was unhappy with having no tracker at all
09:42:56 sean-k-mooney i think its in the etherpad
09:43:04 bauzas https://review.opendev.org/c/openstack/nova/+/866218
09:43:12 bauzas wasn't tracked properly
09:43:34 bauzas hence the miss for the cycle highlights
09:43:39 bauzas doh
09:43:52 sean-k-mooney well i responded to gmann
09:44:01 sean-k-mooney i dont think it need to be in nova sycle highlights
09:44:15 sean-k-mooney i think it shoudl go out in the overall release prelude
09:44:29 bauzas this is anyway too late for the cycle highlights
09:44:36 bauzas I'll just mention it in the prelude
09:44:48 sean-k-mooney we should ahve one section that covers all the secure rbac work for all projects
09:44:57 bauzas and I'll actually look at the generated relnotes to see if I missed anything else
09:45:26 bauzas sean-k-mooney: don't disagreed on your point for the cycle highlights
09:45:34 bauzas this is more a cross-project effort
09:45:45 bauzas but let's mention the nova related implications in the prelude
09:45:59 sean-k-mooney sure
09:46:13 gibi +1
09:46:13 sean-k-mooney it should also be in the general release notes in the upgrades section
09:46:31 sean-k-mooney https://review.opendev.org/c/openstack/nova/+/866218/13/releasenotes/notes/enable-enforce-scope-and-new-defaults-14db8c75b263b599.yaml
09:46:47 bauzas I'm pretty sure the marketing folks will handle that info correctly despite not being said in our cycle highlights :)
09:47:09 sean-k-mooney i would have preferd not to have it in the cycle highlights anyway
09:47:55 sean-k-mooney as i said i think its better to comunitcate this in a cross project way since it really needs to be enabled in a corrdenated way
09:48:13 sean-k-mooney with that said we really do need to complete the service role this cycle
09:48:47 sean-k-mooney to keep on track with the comunity goal schduel
09:49:15 opendevreview Maksim Malchuk proposed openstack/nova stable/xena: Fix to implement 'pack' or 'spread' VM's NUMA cells https://review.opendev.org/c/openstack/nova/+/829804
09:49:20 sean-k-mooney im going to revert the logging patch now https://review.opendev.org/c/openstack/nova/+/873584
09:49:34 sean-k-mooney bauzas: unless you object?
09:49:34 bauzas sean-k-mooney: yes about the service role, but gmann still has a -W on it
09:50:07 bauzas sean-k-mooney: nope, go for it, it's in the list-of-patches-to-merge-before-next-day
09:50:30 sean-k-mooney cool its in the gate
09:51:57 sean-k-mooney this is the base of the first offical SLU release
09:52:04 sean-k-mooney do we need to mentiaon anything beyond that
09:52:17 sean-k-mooney we dont offically support it form yoga
09:52:31 sean-k-mooney that was a test of our tooling/process
09:52:45 sean-k-mooney so while it should work i would not adivse people to use it
09:53:34 sean-k-mooney there wasnt an expecation taht all project support Yoga to Antelope
10:02:01 opendevreview Sylvain Bauza proposed openstack/nova master: Add the 2023.1 Antelope prelude section https://review.opendev.org/c/openstack/nova/+/875380
10:21:47 stephenfin sean-k-mooney: https://review.opendev.org/c/openstack/oslo.db/+/875627 that will fix the annoying warnings you've been seeing in the functional tests
10:37:16 sean-k-mooney nice unfortuhnetly that wont be in 2023.1 at this point
10:37:50 stephenfin yeah, we'll have to backport it
10:40:13 sean-k-mooney i assume once we cut rc1 tomrrow you would like your SQLA2.0 seriese to land sooner rather then later
10:40:39 sean-k-mooney i.e. droping the legacy migration and the other patches you have up
10:40:52 stephenfin yes, please. get it in early
10:41:06 sean-k-mooney ya that is what i was thinking
10:41:33 sean-k-mooney ill try and do a pass of it next week
10:43:24 sean-k-mooney conf.get_location(key, group=group.name).location ==
10:43:26 sean-k-mooney cfg.Locations.opt_default
10:43:36 sean-k-mooney so i tought here was a cleaner way to do that
10:44:03 sean-k-mooney either usign in or a method to check it the option was set from the default
10:44:32 stephenfin There could be. I'm simply not aware of it if so
10:45:11 sean-k-mooney i have not used it personally but i vaguely recall it form the docs
10:45:29 sean-k-mooney the patch looks fine to me but i just want to check if that is a thing quickly
10:46:42 sean-k-mooney stephenfin: ok no you are doing it the way you are ment too https://docs.openstack.org/oslo.config/latest/reference/locations.html
10:46:47 sean-k-mooney that is what i was recalling
10:47:01 sean-k-mooney i tought there was an is_default() or similar
10:47:22 stephenfin yeah, I explicitly wanted to raise a warning if the application (i.e. nova) was setting it too
10:47:28 stephenfin since that's still wrong
10:47:42 sean-k-mooney actully you could use is_user_controlled
10:48:11 sean-k-mooney ah
10:48:23 sean-k-mooney ok so you want to also support set_default and set_override

Earlier   Later