| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-11-14 | |||
| 16:48:03 | bauzas | we can still approve the bp | |
| 16:48:09 | sean-k-mooney | yep | |
| 16:48:14 | bauzas | like we did with nova-net | |
| 16:48:21 | sean-k-mooney | just wanted to clarify that since we expanded the scope at the ptg | |
| 16:48:23 | bauzas | anyone having concerns again ? | |
| 16:48:33 | bauzas | okay so | |
| 16:48:50 | bauzas | #agreed https://blueprints.launchpad.net/nova/+spec/remove-vmware-support to be accepted as a specless BP | |
| 16:48:54 | bauzas | there we go | |
| 16:49:11 | bauzas | sean-k-mooney: I'll just set the LP fields right after the meeting | |
| 16:49:15 | sean-k-mooney | thanks | |
| 16:49:18 | sean-k-mooney | thats all from me | |
| 16:49:23 | bauzas | and we can start to review your patches tomorrow | |
| 16:49:26 | bauzas | cool | |
| 16:49:35 | bauzas | so, let me call it a wrap | |
| 16:49:42 | bauzas | thanks all | |
| 16:49:45 | opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2023/nova.2023-11-14-16.00.log.html | |
| 16:49:45 | opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2023/nova.2023-11-14-16.00.txt | |
| 16:49:45 | opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2023/nova.2023-11-14-16.00.html | |
| 16:49:45 | opendevmeet | Meeting ended Tue Nov 14 16:49:45 2023 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | |
| 16:49:45 | bauzas | #endmeeting | |
| 16:50:56 | dvo-plv | sean-k-mooney, How we can attend tomorrow review. Does it meeting or what ? | |
| 16:51:21 | sean-k-mooney | no its just that tommrrow we are goign to make time to reveiw via gerrit | |
| 16:51:27 | sean-k-mooney | we will be disucssing things here | |
| 16:51:32 | sean-k-mooney | on irc too as needed | |
| 16:52:00 | bauzas | sean-k-mooney: paperwork stamps dully noted. | |
| 16:52:15 | dvo-plv | I see ,okay. Feel free to ping me, thank you | |
| 16:52:22 | bauzas | (on both BPs) | |
| 16:52:30 | elodilles | bauzas: minor clarification: pyhton-novaclient and osc-placement had no relevant changes i think, that's why we only have os-vif Caracal-1 proposed. nova and placement are services, so they don't need Caracal-1 release, hence release patches are not generated for them. (though we could release .0b1 releases, but that is unnecessary as we discussed) | |
| 16:52:47 | bauzas | ack | |
| 17:03:25 | gmann | bauzas: yeah, abandon the hyperV removal spec. i proposed it before our PTG discussion. | |
| 17:39:17 | bauzas | dansmith: can't find the procedural blueprint for https://blueprints.launchpad.net/nova/+spec/libvirt-dev-alias | |
| 17:39:24 | bauzas | fancy creating it ? | |
| 17:39:53 | bauzas | https://specs.openstack.org/openstack/nova-specs/specs/2024.1/approved/libvirt-dev-alias.html links to it | |
| 17:40:31 | dansmith | oh I probably never created it yeah | |
| 17:41:13 | dansmith | bauzas: done | |
| 17:41:40 | bauzas | cool | |
| 17:43:34 | bauzas | okay, https://blueprints.launchpad.net/nova/2024.1 reflects what we have | |
| 17:43:54 | bauzas | (except john's BP which isn't approved yet) | |
| 17:44:21 | bauzas | folks, etherpad just created https://etherpad.opendev.org/p/nova-caracal-status | |
| 17:44:33 | bauzas | I'll curate the list of blueprints to find the relevant gerrit series | |
| 17:44:45 | bauzas | but you should be able to look at it tomorrow | |
| 17:46:27 | sean-k-mooney | cool thanks bauzas | |
| 18:01:21 | opendevreview | Sylvain Bauza proposed openstack/nova master: WIP: libvirt: Cap with max_instances GPU types https://review.opendev.org/c/openstack/nova/+/899625 | |
| 18:01:41 | bauzas | dansmith: sean-k-mooney: squashed my SRIOV patches into a single one | |
| 18:02:04 | bauzas | like dansmith said to me ;) | |
| 18:02:35 | bauzas | operators would then provide the max instances and then restarting nova-compute so the virt driver would delete the ResourceProviders | |
| 18:03:54 | sean-k-mooney | bauzas: i looked at those previosuly but i dont think i found where dansmith said that | |
| 18:04:02 | sean-k-mooney | so i was waiting for an update before looking again | |
| 18:09:10 | bauzas | sean-k-mooney: we discussed this in a gmeet | |
| 18:09:18 | bauzas | hence why no comments | |
| 18:18:35 | opendevreview | Dan Smith proposed openstack/nova master: DNM: Debug some volumes not setting alias https://review.opendev.org/c/openstack/nova/+/900935 | |
| 18:18:35 | opendevreview | Dan Smith proposed openstack/nova master: Detach disks using alias when possible https://review.opendev.org/c/openstack/nova/+/893068 | |
| 18:24:49 | opendevreview | Merged openstack/nova master: Make sqlalchemy-2x job voting again https://review.opendev.org/c/openstack/nova/+/900538 | |
| 20:52:38 | opendevreview | Dan Smith proposed openstack/nova master: DNM: Debug some volumes not setting alias https://review.opendev.org/c/openstack/nova/+/900935 | |
| 22:34:06 | opendevreview | melanie witt proposed openstack/nova master: Add encryption support to convert_image https://review.opendev.org/c/openstack/nova/+/870934 | |
| #openstack-nova - 2023-11-15 | |||
| 08:26:25 | bauzas | happy implementation review day everyone | |
| 08:26:39 | gibi | o/ | |
| 08:26:39 | bauzas | as a reminder, please look at https://etherpad.opendev.org/p/nova-caracal-status | |
| 08:28:06 | bauzas | gibi: ah was just adding your line :p | |
| 08:28:19 | gibi | :) | |
| 08:40:51 | dvo-plv | 0/ | |
| 09:46:44 | gboutry1 | Hi nova, I'm trying to setup live migration and the migration is failing at the step compareHypervisorCPU with CPU doesn't have compatibility. | |
| 09:46:47 | gboutry1 | I'm running an openstack cloud on two identical VMs, each running an hypervisor. here's the capabilities: https://pastebin.ubuntu.com/p/cvvngtk4PG/ | |
| 09:46:50 | gboutry1 | I've tried virsh cpu-compare cpu.xml, which returns CPU described in cpu.xml is identical to host CPU | |
| 09:46:53 | gboutry1 | When using virsh hypervisor-cpu-compare cpu.xml, I get: CPU described in cpu.xml is incompatible with the CPU provided by hypervisor on the host | |
| 09:46:56 | gboutry1 | Is there anyway to get what's the reason hypervisor-cpu-compare is failing ? | |
| 10:22:28 | gboutry1 | Adding the --error flag, I get the following error: error: the CPU is incompatible with host CPU: Host CPU does not provide required features: ht, osxsave, ospke, waitpkg | |
| 10:23:08 | gboutry1 | But I can clearly see them in virsh capabilities | |
| 12:32:21 | gibi | gboutry1: you might hit by https://bugs.launchpad.net/nova/+bug/2039803 | |
| 12:38:13 | gboutry1 | thanks gibi, it looks close enough, do you know what's the workaround sean-k-mooney is talking about ? Maybe setting the cpu_mode to custom with a cpu model instead of configuring with host-model ? | |
| 12:44:18 | sean-k-mooney | loading context | |
| 12:45:10 | sean-k-mooney | but i belvie there are two workarounds | |
| 12:45:12 | sean-k-mooney | https://docs.openstack.org/nova/latest/configuration/config.html#workarounds.skip_cpu_compare_on_dest | |
| 12:45:35 | sean-k-mooney | or ya using a custom model might also work | |
| 13:00:27 | gibi | bauzas: how do you feel about https://review.opendev.org/c/openstack/nova/+/831193/34#message-95b03db3501a7b105700779fb484b5cf740087ea is this style difference worth a respin? | |
| 13:00:40 | gibi | (it is not formatting style difference) | |
| 13:14:36 | sean-k-mooney | it proably should use the ovo approch | |
| 13:15:28 | sean-k-mooney | this is not really an area i look at much in the code base so im generally less opinonated about hwo this is done | |
| 13:25:54 | gibi | yeah I don't know all the possible consequences of our common style so I cannot fully judge what this departure means. At a first glance what Uggla_ wrote works | |
| 13:26:32 | sean-k-mooney | i think it might be more error prone if we are adding filed perhaps but maybe not | |
| 13:27:27 | sean-k-mooney | in general a new object filed results in a new db field too so there is some benifit to delegating to the object implemention | |
| 13:27:40 | sean-k-mooney | presumably if we only set the filed that changed | |
| 13:27:51 | sean-k-mooney | there is a minutly smaller db update | |
| 13:29:35 | gibi | bottom line I won't block on this just wanted to highlight as others might have a reason to block on this :) | |
| 13:31:15 | sean-k-mooney | melaine or dan may have input. jay certenly would have had an opion on it but i cant guess what that would have been | |
| 13:33:27 | gibi | :) | |
| 13:33:32 | gibi | I miss Jay | |
| 13:34:16 | sean-k-mooney | so do i, but he has moved on to better things. he is still aroudn the k8s ecosystem i belive | |
| 13:34:31 | sean-k-mooney | as in he sometimes attends kubecon | |
| 13:48:30 | gibi | yeah when I started the k8s operator work I found his work in github doing k8s operators for aws services | |
| 14:54:49 | bauzas | gibi: sean-k-mooney: sorry guys was disconnecting a bit after a huge load | |
| 14:55:11 | bauzas | gibi: context, about calling the DB directly from the object ? | |
| 14:55:57 | gibi | bauzas: it is the way the db update is implemented by passing individual fields instead of passing an updates dict | |
| 14:56:43 | gibi | we tend to use obj_get_changes and get the dict and pass it to SQLA update() call | |
| 14:56:52 | gibi | s/and/to/ | |
| 14:57:56 | bauzas | I don't disagree with you, see the other comment from PS17 | |
| 14:58:11 | bauzas | https://review.opendev.org/c/openstack/nova/+/831193/comment/6cfa2a63_4b585a14/ | |
| 14:58:32 | bauzas | tl;dr: yeah we no longer need to create a specific interface for API DB | |
| 14:59:45 | bauzas | that said, given the number of changes we have, maybe we should just ask for a new follow-up change | |
| 15:02:15 | dvo-plv | hello, All | |