| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-02-13 | |||
| 01:47:07 | mikal | sean-k-mooney / melwitt / gmann / dansmith: to my mild surprise, after a mere 147 test runs the tempest test for spice-direct is now passing on the nova-ovs-hybrid-plug job. I think that means a whole bunch of changes are probably ready for re-review. Specifically: | |
| 01:47:13 | mikal | spice-direct itself: https://review.opendev.org/c/openstack/nova/+/926876, https://review.opendev.org/c/openstack/nova/+/926877, https://review.opendev.org/c/openstack/nova/+/924844 | |
| 01:47:19 | mikal | tempest testing for spice-direct: https://review.opendev.org/c/openstack/tempest/+/940943, https://review.opendev.org/c/openstack/devstack/+/940838, https://review.opendev.org/c/openstack/nova/+/940835, https://review.opendev.org/c/openstack/nova/+/940873 (the last three are from sean-k-mooney) | |
| 01:47:55 | mikal | The other patch series for USB / sound support is blocked at the moment on https://review.opendev.org/c/openstack/os-traits/+/940418 merging, but it lacks a second +2. | |
| 04:19:21 | gmann | mikal: RE on os-console-auth-tokens schema: for easy way, add it in the new microversion for what you are adding the test with min_microversion. I think that should work and worth trying it instead of adding it for old/base microversion | |
| 04:19:32 | gmann | I will check tempest and devstack change tomorrow | |
| 07:01:17 | mikal | gmann: thanks. I added it to my change, we can always shift it back in time later if anyone ever needs it. | |
| 07:59:44 | opendevreview | Vasyl Saienko proposed openstack/nova master: WIP: Add trunk subports to network metadata https://review.opendev.org/c/openstack/nova/+/941227 | |
| 08:34:48 | tkajinam | this cleanup has been sitting here for some time and I wonder if it can be merged https://review.opendev.org/c/openstack/nova/+/879021 | |
| 10:36:22 | zuhal | hi the root volumes of the virtual machines remain in the attaching process, and since the cinder update volume attachment takes a long time, the Nova gives a cinder client gateway timeout error. how can I make a setting for this? | |
| 11:36:05 | sean-k-mooney | mikal: awsome news | |
| 14:16:03 | opendevreview | Merged openstack/nova master: Bump os-traits to 3.3.0 in requirements https://review.opendev.org/c/openstack/nova/+/940975 | |
| 14:32:52 | bauzas | because https://github.com/openstack/tempest/blob/master/tempest/scenario/test_volume_boot_pattern.py#L222 only fails with my weigher patch on those two jobs https://review.opendev.org/c/openstack/nova/+/940642 | |
| 14:33:55 | bauzas | bottom line, when turning the ImageMetaProps object into a primitive dict, we get some fields that are a CoercedList typ | |
| 14:34:13 | bauzas | and given CoercedList o.vo object doesn't have a hash method, then we fail | |
| 14:38:18 | dansmith | bauzas: that's just when using our old toplevel obj_to_primitive right? I assume because that doesn't go deep enough or know about those o.vo things | |
| 15:16:06 | sean-k-mooney | i see | |
| 15:17:14 | sean-k-mooney | class CoercedList(CoercedCollectionMixin, list): | |
| 15:17:33 | sean-k-mooney | so list does not have a hash function then | |
| 15:18:34 | sean-k-mooney | we should not get CoercedList normlaly form ImageMetaProps | |
| 15:19:46 | sean-k-mooney | oh maybe form tags | |
| 15:19:49 | sean-k-mooney | https://github.com/openstack/nova/blob/master/nova/objects/image_meta.py#L71 | |
| 15:20:02 | sean-k-mooney | sorry that ImageMeta | |
| 15:20:43 | sean-k-mooney | ok so it might be from hw_numa_cpus https://github.com/openstack/nova/blob/master/nova/objects/image_meta.py#L410 | |
| 15:21:21 | sean-k-mooney | in general we dont have any list fies but hw_numa_cpus and hw_numa_mem are | |
| 15:22:08 | opendevreview | Merged openstack/placement master: Bump os-traits to 3.3.0 in requirements https://review.opendev.org/c/openstack/placement/+/940976 | |
| 15:22:44 | sean-k-mooney | we can likely just updat the list type here with a simple hash funtion of that take the hash of all element in the list | |
| 15:22:46 | sean-k-mooney | https://github.com/openstack/nova/blob/master/nova/objects/fields.py#L48-L69 | |
| 15:25:14 | sean-k-mooney | alternitivly instead of storing the key/values in a map or set we can store them as a sting or tuple | |
| 15:27:27 | bauzas | yeah I could avoid the set calculation I think, I need to rethink the design | |
| 15:28:03 | bauzas | and yeah, that probably because of the values, not the keys | |
| 15:28:40 | sean-k-mooney | so instead of "set(inst.image_meta.properties.to_dict().items())" do ```{ "f{key},{value}" for key, value in inst.image_meta.properties.to_dict().items()}``` | |
| 15:29:47 | opendevreview | Takashi Kajinami proposed openstack/os-vif master: Remove os-vif-linuxbridge https://review.opendev.org/c/openstack/os-vif/+/941567 | |
| 15:29:51 | bauzas | that seems a bit hacky to me but this could work indeed | |
| 15:29:53 | sean-k-mooney | f goes on outside ... ```{ f"{key},{value}" for key, value in inst.image_meta.properties.to_dict().items()}``` | |
| 15:30:13 | bauzas | yeah, I got your point, we would hash by strings :D | |
| 15:30:16 | sean-k-mooney | bauzas: it just relies on the fact that all stings are hashable | |
| 15:30:23 | sean-k-mooney | yep | |
| 15:30:32 | bauzas | this is fine | |
| 15:30:51 | bauzas | but providing a fat comment would be nice I guess | |
| 15:30:51 | sean-k-mooney | ideally i think ovo should be fixed to defien a hash on the element of a coherced list | |
| 15:31:08 | sean-k-mooney | but we proably dont want ot hold this on that | |
| 15:31:18 | sean-k-mooney | and ya a comment woudl be good | |
| 15:31:20 | bauzas | yup, FF is arriving | |
| 15:31:26 | dansmith | bauzas: sean-k-mooney I thought we were going to have a convo about a redesign? | |
| 15:31:35 | bauzas | winter is coming | |
| 15:31:36 | sean-k-mooney | we still can | |
| 15:31:42 | sean-k-mooney | dansmith: ^ | |
| 15:31:47 | dansmith | gibi is not sufficiently convinced about the usefulness of this approach anyway | |
| 15:32:04 | sean-k-mooney | in my last review i suggested creating a follow up path | |
| 15:32:24 | sean-k-mooney | to allow per key weights using teh same syntax/code form the metrics weiher | |
| 15:32:26 | bauzas | if we could add that weigher as a first approach, I'm fine with a later refactoring that would fix world's problems | |
| 15:32:27 | opendevreview | Takashi Kajinami proposed openstack/os-vif master: Drop kuryr-kubernetes-tempest https://review.opendev.org/c/openstack/os-vif/+/941568 | |
| 15:32:36 | sean-k-mooney | that way we can decced if we want the added complexity or not | |
| 15:32:59 | bauzas | sean-k-mooney: I still need to review your comments, I mostly focused on the failing jobs | |
| 15:33:01 | gibi | I'm open to a design discussion | |
| 15:34:00 | sean-k-mooney | bauzas: they were pretty minior. | |
| 15:34:25 | sean-k-mooney | basically if we have a more granualr approch to specifying weights per image property | |
| 15:34:48 | sean-k-mooney | i think there is merrit in having the behavior/syntax mirror that of the exisitng metric weigher | |
| 15:34:59 | sean-k-mooney | mainly just for consitency | |
| 15:35:06 | bauzas | okay I can take a look | |
| 15:36:25 | sean-k-mooney | i dont know if that woudl satisfy all open concerns or not but that was the tldr, get the simple version workign and passing then follow patch to extend and discuss later if we finally want to implement supprot for prefered traits | |
| 15:36:47 | bauzas | gibi: reading your comments, you know that we only compare the host properties against the exact image requested properties, right ? | |
| 15:37:36 | bauzas | I originally tried to compare all props as equal, but I eventually considered only the calculation of how many requested props were present on the host | |
| 15:41:39 | dansmith | I think gibi's point is that many irrrelevant props may be requested that dilute the scoring | |
| 15:41:40 | gibi | I'm not sure I see the consequences of it as I don't know what host properties means in this context | |
| 15:41:47 | gibi | dansmith: yes | |
| 15:42:21 | gibi | preferred traits in image metadata implemented as a weigher seems interesting and promising but haven't spent the time to think it through | |
| 15:42:42 | sean-k-mooney | gibi: its something i have wanted since before we actully had required traits | |
| 15:42:47 | gibi | as that would mean each image defines what property it cares about | |
| 15:43:09 | sean-k-mooney | if we supported prefered traits i woudl want to supprot it for both flavor and image ideally | |
| 15:43:42 | sean-k-mooney | but same overall impleation just way the host based on teh prefernce using the provider summaries | |
| 15:44:16 | bauzas | gibi: I need to validate your example in https://review.opendev.org/c/openstack/nova/+/940642/comment/932beb0e_c4933c32/ | |
| 15:46:13 | bauzas | gibi: because while I agree with the fact that VM1 will be on host1 and VM2 on host2, I need to calculate the weight for VM3 | |
| 15:46:50 | dansmith | to make it fully automatic you need to automatically export the trait when an instance is booted on a host, so perhaps some conf knob to expose traits of a thing automatically? l | |
| 15:46:59 | dansmith | auto_expose_image_props = os_type | |
| 15:47:07 | gibi | bauzas: my understanding is more matching properties means higher weights | |
| 15:47:26 | bauzas | you're right indeed, I see the problem now | |
| 15:47:43 | gibi | dansmith: good point, a full dynamic approach needs dynamic traits | |
| 15:47:48 | bauzas | well, that's not really a problem, you're diluting your need into multiple pieces | |
| 15:47:49 | dansmith | I again assert that for a cloudy workload that probably gets stronger with lots of boots of the same image | |
| 15:48:18 | bauzas | I assumed less fine-grained image properties | |
| 15:48:19 | dansmith | if you have tons of snowflake pet images then for sure it will be a very weak force | |
| 15:48:22 | dansmith | right | |
| 15:48:38 | dansmith | and I assumed this was a soft clumping optimization and not a hard packing mechanism | |
| 15:48:45 | bauzas | yup, KISS | |
| 15:48:52 | dansmith | because if you want the latter, it should use stronger guarantees | |
| 15:48:57 | gibi | dansmith: VMs from the same image attract each other I agree. So if we only have a single windows image then the solution works | |
| 15:49:20 | dansmith | gibi: or some small number of them that are probably going to be similar | |
| 15:49:25 | bauzas | we have a meeting in 20 mins | |
| 15:49:28 | bauzas | 10 mins* | |
| 15:49:42 | bauzas | but I think we need a design discussion indeed | |
| 15:50:00 | bauzas | so if you want, let's do that after the internal meeting, ie. 1700UTC | |
| 15:50:24 | bauzas | would 1700UTC work for the three of you ? sean-k-mooney gibi dansmith | |
| 15:50:34 | dansmith | I figure not gibi | |
| 15:50:40 | dansmith | but wfm | |
| 15:51:44 | bauzas | OK, I refreshed my brain on the metricsweigher | |
| 15:51:56 | sean-k-mooney | sure | |
| 15:52:13 | bauzas | fun fact, there was a note with my name, so I already walked that code | |
| 15:52:27 | gibi | dansmith: yeah this is a balancing act. if you have more windows images or if the windows images have a lot of other prop than os_type then you are losing the feature. Now the question is is this compromise acceptable for the customer requesting the feature. Telling them to limit the number of different windows VMs or limit the number of image props (it is already a lot by default from glance) might | |