Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2023-11-15
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
15:02:27 dvo-plv https://review.opendev.org/c/openstack/nova/+/876075/27/nova/api/validation/extra_specs/hw.py#540
15:02:27 dvo-plv I have a question regarding this comment
15:02:28 sean-k-mooney bauzas: sure this coudl be defered to a follow up patch
15:02:34 sean-k-mooney functionlaly it woudl eb equivalent
15:02:57 dvo-plv Do those docs are located in the doc folder in nova project, or I should find them anywhere else ?
15:06:08 bauzas dansmith: so you'll provide a new revision for https://review.opendev.org/c/openstack/nova/+/892800/ ?
15:06:21 dansmith bauzas: in minutes
15:06:38 dansmith that function isn't even used yet, I just added it for symmetry, but I'm changing it anyway
15:06:44 bauzas honestly, I'm fine with using 'assert', we already have a few calls for it in Nova IIRC
15:07:31 opendevreview Dan Smith proposed openstack/nova master: Support setting alias on libvirt disks https://review.opendev.org/c/openstack/nova/+/892800
15:07:32 dansmith me too
15:07:32 opendevreview Dan Smith proposed openstack/nova master: Detach disks using alias when possible https://review.opendev.org/c/openstack/nova/+/893068
15:07:32 opendevreview Dan Smith proposed openstack/nova master: Set libvirt device alias for volumes https://review.opendev.org/c/openstack/nova/+/892801
15:08:04 dansmith it's more that it might be used to parse any alias, and thus be surprising, but the intent was (of course) to only use it to extract the identifier out of the user-specified format
15:08:18 dansmith but when I start using that we can see what makes the most sense
15:13:21 dansmith sean-k-mooney: on the volume id thing, I think that what I was seeing was actually our retries after we detach a volume, we go back and look it up to make sure it's gone,
15:13:28 bauzas anyway, /me just looks at your new revision
15:13:37 dansmith and we'll always fall back to the "old way" because we don't find it via alias (because it's gone)
15:14:00 sean-k-mooney dansmith: ack gone form the trainistae domain right
15:14:08 dansmith so I changed how we do that log to only log if we found it via the old way but not the new way, so we'll see how that looks
15:14:10 dansmith sean-k-mooney: well, both
15:14:17 sean-k-mooney or or just gone because it was detached in between
15:14:37 dansmith gone because we do get_disk(); detach(); get_disk()
15:14:49 sean-k-mooney ah ya ok
15:14:55 dansmith the latter will always fail to find via alias (because it's gone) and try the fallback
15:15:06 sean-k-mooney yep that makes sense
15:17:04 sean-k-mooney dansmith: on the assert thing do we want to put that back in the gate and revisit when you use it later or were you going to respin that anyway
15:18:40 bauzas yeah, in the spec we said we would try to use the alias but we could still support the the previous behaviour
15:19:03 bauzas so, everything looks good to me here
15:19:08 bauzas but I could be wrong
15:20:51 sean-k-mooney i think dansmith just wanted to understand why they were seeing the log message when they were not expecting too and now with the new version wants to minimise the false positives
15:26:35 dansmith the assert is in code that isn't even used, so it's really irrelevant
15:26:55 dansmith I'd rather just merge it as-is and if we start using it on one way or the other we can add the assert back or not
15:26:59 dansmith unrelated to the log message
15:27:19 dansmith sean-k-mooney: and I already respun to do that
15:27:52 sean-k-mooney ack
15:32:21 bauzas sean-k-mooney: good call on the libvirt api not supporting to query per alias
15:32:28 bauzas that's sad at least
15:32:50 bauzas but I wonder, maybe we have a get device per alias
15:33:01 sean-k-mooney we as in nova
15:33:04 sean-k-mooney i dont think so
15:33:33 sean-k-mooney but we can always ask the virt folks if this exists elsewhere in the python lib
15:33:45 bauzas but I don't see anything in https://libvirt.org/html/libvirt-libvirt-nodedev.html
15:34:03 bauzas we have a cap flag but not an alias one
15:35:18 bauzas https://libvirt.org/html/libvirt-libvirt-nodedev.html#virConnectListAllNodeDevices doesn't know a single bit about aliases
15:41:18 bauzas actually, I'm wrong, nodedev is only for host devices, here we're talking of guest devices hence the domain API
15:52:16 opendevreview Merged openstack/nova stable/2023.2: add a regression test for all compute RPCAPI 6.x pinnings for rebuild https://review.opendev.org/c/openstack/nova/+/900309
15:53:04 bauzas one down, two to go
17:27:55 opendevreview Jay Faulkner proposed openstack/nova master: WIP: [ironic] Partition & use cache for list_instance* https://review.opendev.org/c/openstack/nova/+/900831
17:36:33 bauzas stephenfin: or other lords of mypy: could someone tell me how to tell f..k to mypy here https://review.opendev.org/c/openstack/nova/+/899625/4/nova/virt/libvirt/driver.py#7975 ?
17:36:50 bauzas mypy isn't able to infer that the variable will never be None in that case
17:38:03 JayF Does it need to be a Tuple[str, Optional[Any]]?
17:39:02 melwitt bauzas: I think it's just that you need to use a % there instead of a comma?
17:39:05 JayF Any implies none per https://mypy.readthedocs.io/en/stable/kinds_of_types.html#the-any-type
17:39:20 bauzas melwitt: not in LOG()
17:39:58 melwitt but you're assembling the message separately before calling LOG.blah(..., ..., ...)
17:40:11 bauzas JayF: I guess I'll need to annotate the first call
17:40:36 JayF I think melwitt is right
17:40:37 melwitt you could do LOG.warning("mdev type default already set to %s", self.pgpu_type_default)
17:40:41 dansmith sean-k-mooney: yep, that was the problem with the falling-back log message, so that top patch should be good :)
17:40:55 bauzas I can try

Earlier   Later