| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-02-12 | |||
| 18:54:59 | mikal | Turning a console token into hypervisor IP and port requires admin. | |
| 18:55:21 | dansmith | oh because no proxy like normal I guess? | |
| 18:55:36 | sean-k-mooney | right so we allow kerbside to get them but not the normal user | |
| 18:55:46 | dansmith | gotcha | |
| 18:56:00 | mikal | Yeah, a normal user can request a console but then has to ask kerbside to connect to it for them. | |
| 18:56:30 | mikal | Oh, which I guess means I need two clients in this test... | |
| 18:56:34 | mikal | Attempt 11! | |
| 18:58:38 | sean-k-mooney | well you could cheat and jsut do everythin as admin but if you wanted to have a negitive test adn show normal user cant see this then ya | |
| 19:01:45 | opendevreview | Alan Bishop proposed openstack/nova master: Show swap_progress in attachment details https://review.opendev.org/c/openstack/nova/+/941476 | |
| 20:10:06 | opendevreview | Mengyang Zhang proposed openstack/nova master: Add Burst Length Support to Cinder QoS https://review.opendev.org/c/openstack/nova/+/939490 | |
| 20:15:41 | opendevreview | Mengyang Zhang proposed openstack/nova master: Add Burst Length Support to Cinder QoS https://review.opendev.org/c/openstack/nova/+/939490 | |
| 20:25:11 | opendevreview | Artom Lifshitz proposed openstack/nova master: WIP: Add [libvirt]supported_tpm_secret_security https://review.opendev.org/c/openstack/nova/+/940195 | |
| 20:25:11 | opendevreview | Artom Lifshitz proposed openstack/nova master: WIP: Add [libvirt]default_tpm_secret_security https://review.opendev.org/c/openstack/nova/+/940194 | |
| 20:25:12 | opendevreview | Artom Lifshitz proposed openstack/nova master: WIP: Add hw:tpm_secret_security extra spec validation https://review.opendev.org/c/openstack/nova/+/940197 | |
| 20:25:12 | opendevreview | Artom Lifshitz proposed openstack/nova master: WIP: Add hw_tpm_secret_security image property https://review.opendev.org/c/openstack/nova/+/940196 | |
| 20:25:13 | opendevreview | Artom Lifshitz proposed openstack/nova master: WIP: Allow vTPM live migration for `deployment` secret security https://review.opendev.org/c/openstack/nova/+/925771 | |
| 20:25:13 | opendevreview | Artom Lifshitz proposed openstack/nova master: WIP: Ensure secret security policy for TPM instances https://review.opendev.org/c/openstack/nova/+/941062 | |
| 20:25:14 | opendevreview | Artom Lifshitz proposed openstack/nova master: WIP: Modify vTPM LM block to block legacy instances https://review.opendev.org/c/openstack/nova/+/941483 | |
| 21:22:44 | mikal | oh nice, because os-console-auth-tokens previously had zero testing, I also need to define what schema it should have in tempest. | |
| 21:23:10 | mikal | Does anyone have an opinion on if I should just add that schema in the new microversion, or try to work out when it was actually introduced and add it back then? | |
| 21:28:29 | melwitt | gmann: ^ | |
| 21:45:00 | opendevreview | Tobias Urdin proposed openstack/nova master: Add minute to instance_usage_audit_period https://review.opendev.org/c/openstack/nova/+/941488 | |
| 22:34:28 | opendevreview | Michael Still proposed openstack/nova master: libvirt: direct SPICE console object changes https://review.opendev.org/c/openstack/nova/+/926876 | |
| 22:34:29 | opendevreview | Michael Still proposed openstack/nova master: libvirt: allow direct SPICE connections to qemu https://review.opendev.org/c/openstack/nova/+/924844 | |
| 22:34:29 | opendevreview | Michael Still proposed openstack/nova master: libvirt: direct SPICE console database changes https://review.opendev.org/c/openstack/nova/+/926877 | |
| #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 | |