Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2023-11-21
16:57:42 gibi (if we remove the the driver from master the driver is be on the stable branches)
16:57:49 bauzas grandchild: fwiesel: would you be able to attend our meeting on a weekly basis ?
16:57:57 grandchild bauzas: definitely
16:58:07 bauzas okay, here is my proposal then
16:58:09 fwiesel fwiesel: Yes
16:58:19 fwiesel bauzas: Yes
16:58:24 bauzas we could defer the removal until caracal-2
16:58:50 bauzas and every week, I'd add a topic in our meeting about your 3rd party CI
16:59:07 bauzas you could then tell us where you are and what you need
16:59:51 bauzas and if before end of December, we can't really see anything coming, then we would remove the virt driver
17:00:04 fwiesel Fair enough.
17:00:05 grandchild that sounds fine to me, fwiesel?
17:00:10 grandchild k
17:00:19 bauzas any other opinions but me ?
17:00:32 gibi sound OK to me too
17:00:33 bauzas I'm just a code herder, I'm not a L
17:00:44 sean-k-mooney i can defer writing the remaining patches until after milestone 2
17:00:53 sean-k-mooney i have the patch to remove the driver already done
17:01:13 sean-k-mooney but i can wait for the api/object changes until we see if the ci turns up by milestone 2
17:01:18 bauzas okay, then I can write the action item
17:01:35 bauzas sean-k-mooney: I haven't checked, but surely the main patch isn't merged yet, right ?
17:01:44 sean-k-mooney ill -w the removal patch for now
17:01:49 sean-k-mooney its not but i wanted it to be
17:01:54 bauzas okay, sounds a plan
17:01:58 sean-k-mooney i was goign to ask for review today
17:02:09 bauzas and we'll see on a weekly basis how this goes
17:02:16 bauzas lemme write the action
17:02:53 bauzas #agreed we defer the vmwareapi driver removal until caracal-2
17:03:29 bauzas #agreed fwiesel and/or grandchild will report on a weekly basis about their efforts on running a 3rd party CI for vmwareapi
17:03:53 bauzas #action bauzas to create a meeting topic in order to discuss the efforts
17:03:55 grandchild ftr: jkulik is not in the office today, but also in the mix from us :)
17:04:03 bauzas sure
17:04:20 bauzas sean-k-mooney: I appreciate your understanding about the deferral
17:04:35 sean-k-mooney its ok ill ask ye to review other patches instead :P
17:04:38 bauzas grandchild: fwiesel: I aslo appreciate your efforts in trying to bond with us
17:04:38 grandchild sean-k-mooney: we do too! thanks :)
17:04:53 bauzas let it be going
17:05:02 bauzas and we'll see during the next weeks how things go
17:05:12 bauzas we're waaaay overlate
17:05:15 sean-k-mooney before we finish the meeting
17:05:20 sean-k-mooney i did have a topic for this week
17:05:22 bauzas shoot, but quick
17:05:25 sean-k-mooney https://review.opendev.org/c/openstack/nova/+/899381
17:05:36 sean-k-mooney basically does that need a specless blueprint or bug
17:06:02 sean-k-mooney tl;dr libvirt can now tell use how many sev instnace we can create
17:06:09 sean-k-mooney we have a optional config option to do that
17:06:25 sean-k-mooney this patch will just auto detect the amount and report it
17:06:43 sean-k-mooney it was deferd form the orgianl spec because we need libvirt to be modifed to enable this
17:06:45 bauzas I'm fine with approving it as specless but telling them to create a spec if during the implementation reviews we find some design concerns
17:07:02 sean-k-mooney well its actully more or less ready to merge
17:07:18 sean-k-mooney i have one nit and wanted to answer this question before +2ing it
17:07:21 bauzas given the change is already there, it's fine to review it now and ask for a spec if really needed
17:07:26 sean-k-mooney and stephenfin previously +2'd it
17:07:31 bauzas they wouldn't be impacted by the spec freeze
17:07:35 bauzas which is later
17:07:51 bauzas any controversial opinions on it being specless ?
17:08:15 bauzas looks not
17:08:29 bauzas we'll need tkajinam to create a blueprint
17:08:33 sean-k-mooney ok lets ask tkajinam to file a specless blueprint for this then and review it as normal once done
17:08:38 sean-k-mooney ya
17:08:42 sean-k-mooney ok that was it
17:08:45 gibi look OK to me
17:08:52 bauzas #agreed https://review.opendev.org/c/openstack/nova/+/899381 could be specless
17:09:21 bauzas #action tkajinam to create a blueprint and report it to bauzas so that he can late-approve it given above ^$
17:09:33 bauzas okay, we're definitely overlate
17:09:40 bauzas really sorry about that
17:09:42 bauzas thanks all
17:09:46 bauzas #endmeeting
17:09:47 opendevmeet Log: https://meetings.opendev.org/meetings/nova/2023/nova.2023-11-21-16.00.log.html
17:09:47 opendevmeet Minutes (text): https://meetings.opendev.org/meetings/nova/2023/nova.2023-11-21-16.00.txt
17:09:47 opendevmeet Minutes: https://meetings.opendev.org/meetings/nova/2023/nova.2023-11-21-16.00.html
17:09:47 opendevmeet Meeting ended Tue Nov 21 17:09:46 2023 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
17:09:53 elodilles thanks o/
17:10:10 bauzas fwiesel: grandchild: I appreciate your efforts, ping me anytime
17:10:26 fwiesel bauzas: thanks for the offer
17:10:33 elodilles sean-k-mooney: here is the patch about the nova-emulation job removal: https://review.opendev.org/c/openstack/nova/+/901604
17:10:57 sean-k-mooney elodilles: i had one locally too but happy to go with yours
17:11:12 elodilles sean-k-mooney: thx :)
17:11:20 sean-k-mooney i was goign to move it to experimental but im fine to jsut drop it
17:11:23 bauzas gibi: I don't want to be pedantic but I don't want https://review.opendev.org/c/openstack/nova/+/901188 to be a bugfix
17:11:33 sean-k-mooney if someone wants to try and fix it they can just add it back in there patch
17:12:07 elodilles sean-k-mooney: it still remains in the periodic-weekly pipeline at least
17:15:38 sean-k-mooney since peoepls are not reviwign the vmware removal patch can we try and land teh codespell seriese sooner rather then later https://review.opendev.org/c/openstack/nova/+/897092/1
17:21:15 gibi bauzas: I still consider that as a UX bug.
17:21:53 bauzas gibi: we wrote in the spec, I quote :
17:22:04 bauzas "This is the operator’s responsibility to verify that the OS kernel is recent enough to support CPU core tuning and that those CPU cores have their governors supporting both the performance and the powersave profiles."
17:22:59 bauzas if we magically make the feature opt-out, then we leave operators responsible of ensuring that their kernel can support cpu offline
17:23:03 gibi I don't see how that implies that the feature cannot be enabled with zero PCPUs and expect to do nothing
17:23:24 gibi bauzas: I'm not changing the default of the flag. It is still opt in
17:23:40 gibi the operator needs to explicitly enable the feature
17:23:59 gibi with [libvirt]cpu_power_management
17:24:03 gibi with [libvirt]cpu_power_management = True
17:25:20 bauzas touché
17:25:50 gibi what changes is that the operator can enable [libvirt]cpu_power_management = True before decides about the PCPU list of the given host
17:26:24 bauzas I mixed different conversations, one being not public
17:26:30 gibi this allows to enable [libvirt]cpu_power_management globally in a cloud in a deployment engine, and set PCPU config on the hypervisor independetly later
17:27:32 bauzas gibi: given the latter requires a nova-compute restart, I don't really see the benefits of enabling the former before, except if you have a deployment tool and you don't want your users to change that option
17:27:35 sean-k-mooney bauzas: are there specific risks or concerns you have with this change?
17:28:04 sean-k-mooney bauzas: i would eventully like to make [libvirt]cpu_power_management = True the default in nova by the way
17:28:09 bauzas sean-k-mooney: none for the master patch itself

Earlier   Later