| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-07-02 | |||
| 13:02:50 | sean-k-mooney | you can disable datasouce via the cloud init config in yoru image if you wanted too | |
| 13:05:22 | sean-k-mooney | im not ok with https://review.opendev.org/c/openstack/nova/+/953732 by the way | |
| 13:05:51 | sean-k-mooney | fungi: i guess that is why that was being rasised earlier in the week | |
| 13:41:44 | sean-k-mooney | fungi: by the way the dmi info when it is provided to vms is also configuabel via the downstream distobution https://github.com/openstack/nova/blob/2c19c07d5e29ca5445fa6dd45a6117542951714c/nova/version.py#L49-L63 | |
| 13:44:28 | sean-k-mooney | i dont hink we have used this historically downstream | |
| 13:44:37 | sean-k-mooney | but its a thing that can be configured | |
| 13:47:44 | gibi | I'm sorry there was a botched rebased in the bottom of the series... | |
| 13:47:53 | opendevreview | Balazs Gibizer proposed openstack/nova master: Use futurist for _get_default_green_pool() https://review.opendev.org/c/openstack/nova/+/948072 | |
| 13:47:54 | opendevreview | Balazs Gibizer proposed openstack/nova master: Add spawn_on https://review.opendev.org/c/openstack/nova/+/948079 | |
| 13:47:54 | opendevreview | Balazs Gibizer proposed openstack/nova master: Replace utils.spawn_n with spawn https://review.opendev.org/c/openstack/nova/+/948076 | |
| 13:47:55 | opendevreview | Balazs Gibizer proposed openstack/nova master: Move ConductorManager to use spawn_on https://review.opendev.org/c/openstack/nova/+/948187 | |
| 13:47:55 | opendevreview | Balazs Gibizer proposed openstack/nova master: Move ComputeManager to use spawn_on https://review.opendev.org/c/openstack/nova/+/948186 | |
| 13:47:56 | opendevreview | Balazs Gibizer proposed openstack/nova master: Rename DEFAULT_GREEN_POOL to DEFAULT_EXECUTOR https://review.opendev.org/c/openstack/nova/+/948086 | |
| 13:47:56 | opendevreview | Balazs Gibizer proposed openstack/nova master: Make nova.utils.pass_context private https://review.opendev.org/c/openstack/nova/+/948188 | |
| 13:47:57 | opendevreview | Balazs Gibizer proposed openstack/nova master: Print ThreadPool statistics https://review.opendev.org/c/openstack/nova/+/948340 | |
| 13:47:57 | opendevreview | Balazs Gibizer proposed openstack/nova master: Make the default executor configurable https://review.opendev.org/c/openstack/nova/+/948087 | |
| 13:47:59 | opendevreview | Balazs Gibizer proposed openstack/nova master: Allow services to start with threading https://review.opendev.org/c/openstack/nova/+/948311 | |
| 13:47:59 | opendevreview | Balazs Gibizer proposed openstack/nova master: Document native threading mode and tuneables https://review.opendev.org/c/openstack/nova/+/949364 | |
| 13:48:01 | opendevreview | Balazs Gibizer proposed openstack/nova master: Do not yield in threading mode https://review.opendev.org/c/openstack/nova/+/950994 | |
| 13:48:01 | opendevreview | Balazs Gibizer proposed openstack/nova master: Run nova-next with n-sch in threading mode https://review.opendev.org/c/openstack/nova/+/948450 | |
| 13:48:03 | opendevreview | Balazs Gibizer proposed openstack/nova master: Warn on long task wait time for executor https://review.opendev.org/c/openstack/nova/+/952666 | |
| 13:48:03 | opendevreview | Balazs Gibizer proposed openstack/nova master: Run nova-api and -metadata in threaded mode https://review.opendev.org/c/openstack/nova/+/951957 | |
| 13:48:05 | opendevreview | Balazs Gibizer proposed openstack/nova master: Run unit test with threading mode https://review.opendev.org/c/openstack/nova/+/953475 | |
| 13:48:05 | opendevreview | Balazs Gibizer proposed openstack/nova master: Allow to start unit test without eventlet https://review.opendev.org/c/openstack/nova/+/953436 | |
| 13:48:07 | opendevreview | Balazs Gibizer proposed openstack/nova master: [test]RPC using threading or eventlet selectively https://review.opendev.org/c/openstack/nova/+/953815 | |
| 13:49:53 | opendevreview | Balazs Gibizer proposed openstack/nova master: FUP: Translate scatter-gather to futurist https://review.opendev.org/c/openstack/nova/+/953338 | |
| 14:31:14 | opendevreview | Kamil Sambor proposed openstack/nova master: Replace eventlet.event.Event with threading.Event https://review.opendev.org/c/openstack/nova/+/949754 | |
| 14:32:52 | gibi | eventlet sycn https://meet.google.com/bcy-uqoz-hje?authuser=0 | |
| 14:53:03 | fungi | sean-k-mooney: thanks, yeah revisiting my recollections of the original bug, it's that cloud-init is guessing whether it's booting in an openstack environment based on the dmi data, but that only works for qemu virtual machines on x86, so on e.g. arm cloud-init can't decide whether it's safe to assume the metadata source is legitimate or potentially spoofed by some attacker | |
| 14:53:05 | fungi | because it doesn't know whether it's in an openstack cloud | |
| 14:56:24 | sean-k-mooney | right but you can contol that by the cloud-init config in the guest when you build the image | |
| 14:56:39 | sean-k-mooney | adn the expect behiovr is to enumerate all data souces that are enabled in the image | |
| 14:57:02 | sean-k-mooney | so to me removign the enumeration is fundementaly breakign how this was inteded to work | |
| 14:57:15 | sean-k-mooney | no i think they are jsut chagnign there defaults in there config | |
| 14:57:19 | sean-k-mooney | rather then entirly removing it | |
| 14:58:21 | sean-k-mooney | i.e. if you expiclty customise an image and enable the openstack data souce adn upload it to glance | |
| 14:58:35 | sean-k-mooney | you can still use ti with vmware or lxc or ironic | |
| 15:01:14 | sean-k-mooney | i would not be surpised if some distros decide to revert back when buidling there cloud images | |
| 15:01:46 | sean-k-mooney | fungi: glean just uses config drive right, ye never implemented the metadata rest api? | |
| 15:07:27 | fungi | i think so, we prefer dhcp/slaac+ra but if the cloud needs to set network configuration through metadata then we rely on glean to pull that from the configdrive because our experience with network metadata sources has been bad | |
| 15:21:49 | gmaan | stephenfin: RE v2.0, thanks for updates. +W on the deprecation way. | |
| 15:22:18 | stephenfin | ta | |
| 15:23:18 | gmaan | gibi: yeah, that was my main concern on v2.0 direct removal as it was not marked as deprecated or not supported. at least giving deprecation phase to users (if any) can come forward if they need it for some more time and why not using v2.1 | |
| 15:31:18 | opendevreview | ribaudr proposed openstack/nova-specs master: Enable memfd support for shared memory backing https://review.opendev.org/c/openstack/nova-specs/+/951689 | |
| 15:32:17 | gibi | gmaan: cool, I agree that we need a deprecation first | |
| 15:32:57 | Uggla | sean-k-mooney, if you can have a look at 951689: Enable memfd support for shared memory backing | https://review.opendev.org/c/openstack/nova-specs/+/951689 let me know if I manage to capture all you inputs. | |
| 15:33:14 | Uggla | sean-k-mooney, no urgency on that one. | |
| 15:33:36 | gibi | fyi, Sree while verifying PCI in Placement caught a nice, long standing bug in our pci tracker https://bugs.launchpad.net/nova/+bug/2115729 | |
| 15:34:56 | opendevreview | Merged openstack/nova-specs master: Deprecate v2.0 API https://review.opendev.org/c/openstack/nova-specs/+/951949 | |
| 15:48:30 | Uggla | gibi, I have seen this bug yesterday. kudos to Sree. I guess I can triage it as a valid one ? | |
| 15:48:47 | gibi | I did the triage now that I found the root cause | |
| 15:49:03 | gibi | I will push a fix in 30 mins... | |
| 15:50:50 | Uggla | gibi, faster than light ! | |
| 15:54:37 | gibi | this is a typical bug where finding the root cause is the hard thing, fixing it is the easy | |
| 16:05:02 | ratailor | gmaan, could you please provide your feedback on https://review.opendev.org/c/openstack/nova-specs/+/929780/ my replies ? | |
| 16:08:33 | opendevreview | Rajesh Tailor proposed openstack/nova-specs master: Show finish_time field in instance action show https://review.opendev.org/c/openstack/nova-specs/+/929780 | |
| 16:09:05 | ratailor | sean-k-mooney, gibi could you please also review ^^ as tomorrow is last date for FF. | |
| 16:12:16 | opendevreview | Balazs Gibizer proposed openstack/nova master: Reproduce that only half of the PCI devs are removed https://review.opendev.org/c/openstack/nova/+/953971 | |
| 16:12:17 | opendevreview | Balazs Gibizer proposed openstack/nova master: Fix pci_tracker.save to delete all removed devs https://review.opendev.org/c/openstack/nova/+/953972 | |
| 16:12:46 | gmaan | ratailor: sure, will check today | |
| 16:13:20 | ratailor | gmaan, Thanks! | |
| 18:29:46 | opendevreview | Alexey Stupnikov proposed openstack/nova master: Use updated_at to purge shadow_instance_extra https://review.opendev.org/c/openstack/nova/+/953984 | |
| 18:33:58 | opendevreview | Alexey Stupnikov proposed openstack/nova master: Use updated_at to purge shadow_instance_extra https://review.opendev.org/c/openstack/nova/+/953984 | |
| 18:41:46 | sean-k-mooney | gibi: bauzas Uggla did ye look at my verion of the iothreads spec by the wayhttps://review.opendev.org/c/openstack/nova-specs/+/953940/2/specs/2025.2/approved/dynamic-vm-iothreads.rst | |
| 18:42:02 | sean-k-mooney | we are unlikely to merge either by tomorrow but i fell like my version is closer | |
| 18:50:55 | opendevreview | Merged openstack/nova-specs master: Add flavor-search-by-name spec https://review.opendev.org/c/openstack/nova-specs/+/940440 | |
| 19:28:45 | Uggla | combine the two. | |
| 19:28:45 | Uggla | sean-k-mooney, yep I have quickly looked at it. Tbh I think from technical point of view It looks great. I'm just annoyed about how masahito feels about it. I'd like a kind of co authoring and make sure his need is fulfill by the spec too. I will discuss with him tomorrow, because I'd like to explain, the goal is not to overwrite his spec but | |
| 19:31:24 | mikal | hard coded zeroconf IP address on any of the clouds I can think of. | |
| 19:31:24 | mikal | fungi: my general recollection of this decade old coversation aligns with what sean-k-mooney said. Config drive v2 was always meant as a stop gap until everyone was using the metadata service. It really only existed at all because it was copied from AWS. I'm confused by your x86 address detection comments because the metadata service just uses a | |
| 19:32:07 | mikal | fungi: certainly a lot of the warts in config drive (like it originally not being able to be updated, although I think maybe that's fixed now) were because it was seen as a temporary thing. | |
| 19:35:41 | fungi | mikal: i was mis-remembering the bug, looking at the cloud-init commit it's "nova detection" really. they want to only contact the metadata server address for discovery if run in an openstack (or ec2) cloud, so are checking dmi to determine if it's safe to do so, but that check is only viable on x86 | |
| 19:36:51 | fungi | so when it comes to booting generic non-x86 distro cloud images with cloud-init included, the recommendation is to rely on configdrive instead | |
| 19:37:06 | mikal | Honestly most of that DMI stuff is a bit dumb. That data exists in metadata, why do we ram it into two places one of which doesn't work on other architectures? | |
| 19:38:06 | fungi | yeah, and so if nova didn't do that even on x86, then cloud-init would really just recommend distros go back to making openstack-specific images so they could set the override in the kernel command-line or an embedded conffile | |
| 19:38:40 | fungi | (or suggest always using configdrive maybe) | |
| 19:38:42 | mikal | I'm not here to hate on config drive. My point is more that its outlived its expected life, had some weird implementation choices because of the time it was done in, and probably needs some love if its really here forever. | |
| 19:39:14 | opendevreview | Brett Holman proposed openstack/nova master: Add DMI data to non-x86 architectures https://review.opendev.org/c/openstack/nova/+/953989 | |
| 19:39:35 | mikal | Like for example it execs a command line to build the ISO image, solely because the only library we could find at the time to do it nicely was GPL and we refused to use GPL dependencies. | |
| 19:39:37 | fungi | agreed, it has challenges, for example the earlier change at the start of this discussion about using virtio for cdrom devices by default, because debian doesn't include ahci drivers in their genericcloud kernel configs | |
| 19:40:07 | mikal | FAT config drives should work too? IIRC it doesn't _have_ to be a CDROM, it just defaults to that? | |
| 19:40:12 | mikal | Its been a long time. | |
| 19:40:52 | fungi | it probably could be any kind of block device, i think it was virtual cd by convention so not sure if that assumption is baked into places (e.g. in cloud-init) | |
| 19:42:11 | fungi | granted, forcing a different device type is still going to be a custom image property on upload or some similar override, if it's not nova's default | |
| 19:51:47 | mikal | So cloud-init will only probe for a couple of things to match -- device ID matters (config2) and type. The probing code only looks for CDROMs or FAT formatted disks IIRC. | |
| 19:53:10 | mikal | Honestly, most of the people I know who really use metadata use it as a poor man's replacement for Nova not having some sort of mature out of band agent thing. They really want AWS SSM agent or equivalent -- https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent.html. | |
| 19:54:17 | mikal | We could do the same with either a custom agent or the qemu agent (although the qemu agent has some pretty big limitations), that bit isn't too hard. The hard bit is marshalling the requests into the instance. That likely involves some sort of per-instance queue that Nova doesn't have right now. | |
| 19:58:38 | fungi | yeah, an actual communication channel from host to guest at least, if not bi-directional | |
| 19:59:04 | mikal | Yeah, specifically one which doesn't not require networking to be configured and working. | |
| 19:59:38 | mikal | I worked for a training startup for a bit... We did all sorts of contortions to rescue VMs when students messed up their networking. This would have made it so much easier. | |
| 19:59:49 | fungi | a fifo-like proc interface in the kernel or something would be amazing | |
| 20:00:29 | fungi | and/or pseudofiles like device drivers tend to expose | |
| 20:00:32 | mikal | So qemu-agent uses a unix domain socket on the outside and virtio-serial on the inside and speaks JSON blobs, which is a bit terrible. Serial means only one talker at a time. | |
| 20:01:39 | fungi | though at boot time, one talker in the guest is generally sufficient? | |
| 20:01:48 | mikal | ShakenFist does this with a unix domain socket on the outside and virtio-vsock on the inside, and speaks protobufs. That's actually really cool if I don't say so myself because the in-guest agent can just run a socket server like you're used to and serve N requests at the same time because virtio-vsock does all the multiplexing for you. | |
| 20:01:59 | fungi | or maybe not these days, with the advent of parallel boot processing | |
| 20:02:40 | mikal | Serialized requests forces you to come up with some sort of queueing / locking mechanism to handle the case of multiplem requests, even if its not used much. | |
| 20:03:14 | fungi | the protobuf design sounds nice, if only protobuf libraries weren't such shifting sand these days (ut maybe they're getting better) | |
| 20:03:53 | mikal | https://www.madebymikal.com/virtio-vsock-python-examples-of-running-the-server-in-the-guest/ is what I wrote up when I was playing with virtio-vsock. | |
| 20:06:23 | fungi | yeah, i guess low-level socket access like that is probably enough for these cases, you don't need google's own protobuf libs | |