Earlier  
Posted Nick Remark
#openstack-nova - 2023-01-10
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 opendevreview Merged openstack/nova stable/wallaby: Adapt websocketproxy tests for SimpleHTTPServer fix https://review.opendev.org/c/openstack/nova/+/866194
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: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

Earlier   Later