| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-04-21 | |||
| 12:33:50 | gibi | kashyap: your test code calls https://github.com/openstack/nova/blob/dc30a7e6d19509ce34cb89ffcdb4ff2c36469d89/nova/virt/libvirt/config.py#L75 that is pretty empty | |
| 12:34:13 | gibi | wait, no | |
| 12:34:19 | gibi | hang on | |
| 12:35:18 | gibi | :D | |
| 12:35:41 | gibi | it correctly calls nova.virt.libvirt.config.LibvirtConfigCPU.parse_dom | |
| 12:37:46 | kashyap | Yea, did you put a breakpoint() to see it | |
| 12:39:52 | kashyap | All I want to assert is that the test is parsing the <cpu> element correctly. So assert for the presence of 'model' / 'vendor' etc? | |
| 12:42:22 | gibi | does nova use LibvirtConfigCPU to parse xml? I only see existing tests that verify to_xml but no parse_dom | |
| 12:45:19 | gibi | it seems that parsing code in LibvirtConfigCPU.parse_dom is either incorrect or the example XML you use is incorrect | |
| 12:45:20 | kashyap | gibi: Yeah, I didn't find any of parse_dom either | |
| 12:46:10 | gibi | the parser code assumes that everything is directly under <cpu> but in your example XML the tags are under cpu/mode | |
| 12:46:13 | kashyap | gibi: The example XML is ... trimmed down output from running `virsh domcapabilities` on my computer | |
| 12:46:56 | gibi | so the exta nesting by "mode" is makes the parse_dom to find nothing to match | |
| 12:47:07 | kashyap | gibi: Run `virsh domcapabilities` and you'll see tags under several modes | |
| 12:47:58 | gibi | then you need to handle the extra mode nesting in the parse_dom code | |
| 12:48:39 | gibi | but be aware that the to_xml code also emits the xml without the extra mode nesting right now | |
| 12:48:50 | kashyap | gibi: Hmm, I see. So, here's a test you do: the "everything under <cpu>" from `virsh capabilities` | |
| 12:49:02 | kashyap | So carefully run these two commands and compare the <cpu> bits: | |
| 12:49:30 | kashyap | - virsh capabilities # notice the <cpu> — everything is under it; and it has no "policy" for features | |
| 12:49:30 | kashyap | - virsh capabilities # notice the <cpu> — everything is under it; and it has no "policy" for features | |
| 12:49:51 | kashyap | - virsh domcapabilities # notice the <cpu> and compare w/ the above | |
| 12:50:25 | gibi | yeah I see | |
| 12:50:40 | gibi | so capabilities emits different structure than domcapabilities | |
| 12:50:53 | kashyap | Yes, indeed. | |
| 12:50:56 | gibi | so probably we need a different config object to parse the two different model | |
| 12:51:18 | gibi | as I assume nova still uses getCapabilities even after we start using getDomCapabitilies | |
| 12:51:39 | gibi | or can we simply ignore the mode part of the domcapabilities? | |
| 12:51:54 | gibi | as we can assume that mode is host-model | |
| 12:52:34 | gibi | I have to step away from the keyboard for a while now but I will be back later this afternoon | |
| 12:52:48 | kashyap | Sure, no prob | |
| 12:55:14 | kashyap | I think we can ignore the mode part here, as we indeed know that it's of 'host-model' | |
| 12:55:18 | kashyap | And that works | |
| 12:57:31 | kashyap | gibi: When you're back: indeed, putting the stuff under <cpu> does resolve the test prob. (Also, near as I see, I don't think we need a diff config object) | |
| 13:04:41 | sean-k-mooney | form a consitncy point of view we should have different config objects | |
| 13:04:53 | sean-k-mooney | we have one config object per element type in the xml | |
| 13:05:13 | sean-k-mooney | so we shoudl not use the same python object to parse both the dom caps and normal caps | |
| 13:05:27 | sean-k-mooney | kashyap: ^ | |
| 13:05:35 | sean-k-mooney | so i agree with gibi here | |
| 13:06:13 | kashyap | sean-k-mooney: There already exists a config object for domCaps | |
| 13:06:32 | kashyap | Also, Gibi was wondering out loud, and was not asking. I'll dig a bit more and see what's required here. | |
| 13:06:40 | sean-k-mooney | ack | |
| 13:13:34 | opendevreview | Merged openstack/nova stable/xena: Reattach mdevs to guest on resume https://review.opendev.org/c/openstack/nova/+/821126 | |
| 13:51:33 | gibi | sean-k-mooney, kashyap: if we can always treat caps and domcaps as equivalent with the assumption of mode host-mode in case of domcaps, then I'm OK to keep a single config object for both | |
| 13:54:33 | gibi | more preciesly *if we can treat the cpu part of caps and domcaps | |
| 13:55:57 | kashyap | gibi: Good point. A related thing, that you've noticed yourself, is domCaps also reports "policy" | |
| 13:57:08 | kashyap | gibi: And I _don't_ think we can treat the CPU part of caps and domCaps as same ... because, here, see the diff in features from both, from my laptop - they're not equal: | |
| 14:00:05 | kashyap | gibi: https://paste.opendev.org/show/bvMLvWCzjusOKOyzgsOi/ | |
| 14:00:22 | kashyap | They're not equal, you see | |
| 14:00:55 | kashyap | (Ignore line-1, it's accidental) | |
| 14:01:37 | gibi | ahh, I see, if we cannot ignore the diff as we depend on the topology for example | |
| 14:01:58 | kashyap | Lemme check with Jiri Denemark from libvirt | |
| 14:02:00 | gibi | so I have to side with sean-k-mooney that we need to split the config model | |
| 14:02:51 | gibi | and we can add helpers to move data between caps and domcaps object when needed | |
| 14:03:08 | gibi | kashyap: sure, more viewpoint helps | |
| 14:06:02 | sean-k-mooney | the feature listed in virsh capabliteis are the cpu feature on the host | |
| 14:06:24 | sean-k-mooney | and the model listed is the closes standard model to the host feature set | |
| 14:06:45 | kashyap | Yeah, as I wrote in my small primer on differences: | |
| 14:06:50 | sean-k-mooney | wehn we use dom caps that actully provides what will be used by the vm when that model is selected | |
| 14:07:04 | kashyap | sean-k-mooney: No, not "what will be used by the VM" - rather: | |
| 14:07:43 | sean-k-mooney | its providing the content of what we will be generted in the libvirt domain xml | |
| 14:07:48 | sean-k-mooney | if we requested host model | |
| 14:08:15 | sean-k-mooney | which is what i ment by "what will be used" in my previous sentence | |
| 14:08:16 | kashyap | sean-k-mooney: It answers two questions: (a) whether a feature is supported by the host; and (b) whether it is supported by a given QEMU binary running on the host | |
| 14:09:16 | sean-k-mooney | artom: gibi by the way i can confirm that https://review.opendev.org/c/openstack/os-brick/+/838871 fixes the unit test failures | |
| 14:09:52 | sean-k-mooney | so this backport https://review.opendev.org/q/topic:bug%252F1947370 | |
| 14:09:58 | sean-k-mooney | is what causes the lock path issues | |
| 14:10:14 | sean-k-mooney | the reviert is not nessisarly the correct approch | |
| 14:10:25 | sean-k-mooney | but the backport made a previously optional config option required | |
| 14:10:39 | sean-k-mooney | we neither set the config option in our test or the enviornmental variable | |
| 14:10:56 | sean-k-mooney | so strictly speaking i do no think os-brick shoudl have backported that change as written | |
| 14:11:40 | sean-k-mooney | it did not comply with satable policy since it requirs config to be updated. | |
| 14:11:53 | sean-k-mooney | elodilles:^ correct me if that is a wrong intepretation | |
| 14:12:21 | sean-k-mooney | if they provided a sane default then i think it woudl have been fine | |
| 14:12:49 | sean-k-mooney | like /run/os-brick/lock or /tmp/os-brick/lock | |
| 14:13:10 | sean-k-mooney | but in its current form its a breaking change for any deployemnt that did not set that | |
| 14:40:28 | sean-k-mooney | artom: gibi https://bugs.launchpad.net/os-brick/+bug/1969794 | |
| 14:53:35 | elodilles | sean-k-mooney: yepp, that's against stable policy and was discussed here with cinder team: https://review.opendev.org/c/openstack/releases/+/829590 | |
| 14:54:32 | gibi | sean-k-mooney: good catch | |
| 14:55:32 | sean-k-mooney | so the option is form oslo_concurrency | |
| 14:55:40 | sean-k-mooney | not form os-brick or nova | |
| 14:55:47 | sean-k-mooney | so we can adress this in a few ways | |
| 14:56:03 | sean-k-mooney | in nova we could jsut set the env varable to somethign sane in the tox.ini | |
| 14:56:21 | sean-k-mooney | that woudl be a minimal fix we could also mock some of the calls in a fixture | |
| 14:56:44 | sean-k-mooney | apprently both nova and cinder docuemtn that this shoudl be set in the config in our install guides | |
| 14:56:55 | sean-k-mooney | so in practice all cloud should have the config option set | |
| 14:57:11 | gibi | so I assume nova also uses that config option for its of file lock | |
| 14:57:12 | sean-k-mooney | elodilles: gibi any prefernce on how to proceed. | |
| 14:57:20 | sean-k-mooney | yes | |
| 14:57:23 | sean-k-mooney | we do | |
| 14:57:42 | gibi | so somewhere in the nova test env we already provide a default for that option | |
| 14:57:44 | sean-k-mooney | and os-brick is runnign in novas process space so its reading our config value | |
| 14:58:04 | sean-k-mooney | gibi: that or we mock the locking code | |
| 14:58:09 | gibi | yeah | |
| 14:58:09 | sean-k-mooney | so it does not write to disk | |
| 14:58:27 | gibi | we already do something so that the nova usage of that opt is covered | |
| 14:58:28 | sean-k-mooney | in this case since its failing its actully trying to create a file systm lock in the unit test | |
| 14:58:31 | sean-k-mooney | which it shoudl not be | |
| 14:58:48 | sean-k-mooney | i woudl guess we are just missing a fixture in those tets | |
| 14:59:00 | gibi | yeah that is what I think too | |
| 14:59:09 | gibi | we need to find what is missing and extend the fixture | |