Earlier  
Posted Nick Remark
#openstack-nova - 2025-07-01
17:39:05 Uggla ok
17:39:19 sean-k-mooney im fine with fixing the docs in general and if they want to add a patch to add it as a preqeusit for all distos then ok but i dont wnat to need to keep updating how to install rabbit if we can avoid it
17:40:56 sean-k-mooney https://review.opendev.org/c/openstack/nova/+/938702
17:41:32 sean-k-mooney so there is a patch for it a diffent bug https://bugs.launchpad.net/nova/+bug/2091585
17:41:45 sean-k-mooney so we proably shoudl clsoe the new one as a duplicate of that one
17:42:44 sean-k-mooney ill just do that now if there is no objetion we do not need two bugs for that
17:44:20 sean-k-mooney there is apprenly a commen guide that covers the install we can just link too https://docs.openstack.org/install-guide/environment-messaging-rdo.html
17:44:53 sean-k-mooney there is a ubuntu version too https://docs.openstack.org/install-guide/environment-messaging-ubuntu.html
21:55:56 mikal At least the ceph CI error has changed this morning?
21:55:56 mikal The following packages have unmet dependencies:
21:55:56 mikal qemu-block-extra : Depends: qemu-system-any (= 1:8.2.2+ds-0ubuntu1.7) or
21:55:56 mikal qemu-utils (= 1:8.2.2+ds-0ubuntu1.7) but 1:8.2.2+ds-0ubuntu1.8 is to be installed
21:55:56 mikal E: Unable to correct problems, you have held broken packages.
22:33:42 opendevreview Merged openstack/nova master: doc: Adding link for RabbitMQ installation during nova deployment on controller node. https://review.opendev.org/c/openstack/nova/+/938702
#openstack-nova - 2025-07-02
06:44:01 r-taketn Hi cores. I would appreciate it if you could review the SEV-ES code(https://review.opendev.org/q/topic:%22bp/amd-sev-es-libvirt-support%22) for the 2025.2 release. The SEV-ES code looks good to me. I apologize if this is already part of your review plan (https://etherpad.opendev.org/p/nova-2025.2-status#L88).
09:12:30 opendevreview Masahito Muroi proposed openstack/nova-specs master: Add spec for virtio-blk multiqueue and iothreads extra_spec https://review.opendev.org/c/openstack/nova-specs/+/951636
09:16:18 frickler mikal: looks like we might need to evict more pkgs from our mirror. or ubuntu needs to fix this be releasing pkgs with a bumped version
09:20:43 frickler oh, seems this was discussed in the glance channel already
09:38:38 mikal Oh, I'm not in the glance channel so I haven't seen that.
09:38:45 mikal Is there anything you need me to do?
09:44:41 frickler mikal: iiuc fungi was working on this, I'm not sure if the cleanup was completed already. do you still see new failures currently?
09:47:56 mikal I haven't tried for a few hours. Let me try again again now.
09:48:38 mikal Oh I lie, I kicked off a recheck an hour ago. Its still running. Results will be at https://review.opendev.org/c/openstack/nova/+/926126 when they're done.
09:49:26 mikal In other questioins... I am unclear on what problem Glean is solving, apart from cloud-init being a bit big and complicated these days. Someone please to explain?
10:01:42 opendevreview Kamil Sambor proposed openstack/nova master: Replace eventlet.event.Event with threading.Event https://review.opendev.org/c/openstack/nova/+/949754
10:02:43 opendevreview Kamil Sambor proposed openstack/nova master: Replace eventlet.event.Event with threading.Event https://review.opendev.org/c/openstack/nova/+/949754
10:06:16 frickler mikal: yes, cloud-init pulls in a lot of python dependencies at the distro level, which may conflict with dependencies for OpenStack projects, which is why we try to avoid it for CI purposes
10:07:45 frickler also no failures so far, so looks like things might be fixed https://zuul.opendev.org/t/openstack/status?change=926126
10:16:18 Uggla sean-k-mooney, gibi, I know you are busy, but It would be great if you can have a look at 951636: Add spec for virtio-blk multiqueue and iothreads extra_spec | https://review.opendev.org/c/openstack/nova-specs/+/951636. masahito updated it and I reviewed it on my side. So there is still a chance to have this spec approved for this cycle.
10:21:25 sean-k-mooney hum ok,,, i was goign to write a differnt version of that spec(im 2/3rd of the way though) since i assuemd they were not going to update it at this point and i had some other ideas on how to do it
10:28:21 mikal frickler: that makes sense. So it's only intended for CI workloads? Config drive was meant to be gone by now...
10:31:31 gibi Uggla: left couple of questions ther
10:31:32 gibi e
11:03:17 opendevreview sean mooney proposed openstack/nova-specs master: support iothread for nova vms https://review.opendev.org/c/openstack/nova-specs/+/953940
11:03:31 sean-k-mooney that is my version of how to do that ^
11:24:32 opendevreview Balazs Gibizer proposed openstack/nova master: FUP: Translate scatter-gather to futurist https://review.opendev.org/c/openstack/nova/+/953338
11:24:32 opendevreview Balazs Gibizer proposed openstack/nova master: FUP: Use futurist for _get_default_green_pool() https://review.opendev.org/c/openstack/nova/+/953339
11:44:25 stephenfin bauzas: We're waiting for you on https://review.opendev.org/c/openstack/nova-specs/+/940440
11:56:33 frickler mikal: in the current state CI is the only remaining use I'm aware of, yes. is config drive deprecated? that's news to me
11:57:33 stephenfin gmaan: I've proposed deprecating the v2.0 API for now, and removing in 2 releases. That will cause keystoneauth and Gophercloud to ignore it by default during discovery which is a good first step
12:00:39 opendevreview Stephen Finucane proposed openstack/nova-specs master: Deprecate v2.0 API https://review.opendev.org/c/openstack/nova-specs/+/951949
12:01:10 opendevreview sean mooney proposed openstack/nova-specs master: support iothread for nova vms https://review.opendev.org/c/openstack/nova-specs/+/953940
12:05:23 sean-k-mooney frickler: its not deprecated and we have no plans to remvoe it
12:05:34 gibi stephenfin: wasn't we deprecated v2.0 already in the past?
12:05:41 sean-k-mooney frickler: we even turn it on by default in our downstream installer
12:05:55 stephenfin gibi: It still reports SUPPORTED from the root API doc
12:06:12 sean-k-mooney mikal: we hyave no plans to remove config drive.
12:06:14 stephenfin so not from the API perspective, afaict
12:11:18 frickler sean-k-mooney: ah, thx for confirming
12:11:52 sean-k-mooney we did deprecate https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.config_drive_format a while ago
12:12:06 sean-k-mooney but keepign vfat does tno really hurt so we never remvoed it
12:12:25 sean-k-mooney the plan was to only supprot isos onc ethe very very old libivrt bug was resolved
12:13:26 sean-k-mooney its one of those thing where until it brekas the effort to remove vfat support is not woth the gain
12:22:39 gibi stephenfin: ack, that is a bummer but the I agree to deprecate
12:23:14 fungi mikal: can you expand on what "config drive was meant to be gone by now" means? is there a better metadata source that doesn't depend on flaky/inconsistent networking or hard-coded addresses? see also the latest cloud-init security fix where using configdrive is literally the recommendation for non-x86 guests now
12:24:24 fungi the reason we use configdrive with glean is because network-supplied metadata has been pretty terrible in lots of clouds
12:24:26 gibi brace for impact...
12:24:31 opendevreview Balazs Gibizer proposed openstack/nova master: Add spawn_on https://review.opendev.org/c/openstack/nova/+/948079
12:24:32 opendevreview Balazs Gibizer proposed openstack/nova master: Move ComputeManager to use spawn_on https://review.opendev.org/c/openstack/nova/+/948186
12:24:32 opendevreview Balazs Gibizer proposed openstack/nova master: Move ConductorManager to use spawn_on https://review.opendev.org/c/openstack/nova/+/948187
12:24:33 opendevreview Balazs Gibizer proposed openstack/nova master: Make nova.utils.pass_context private https://review.opendev.org/c/openstack/nova/+/948188
12:24:33 opendevreview Balazs Gibizer proposed openstack/nova master: Rename DEFAULT_GREEN_POOL to DEFAULT_EXECUTOR https://review.opendev.org/c/openstack/nova/+/948086
12:24:34 opendevreview Balazs Gibizer proposed openstack/nova master: Make the default executor configurable https://review.opendev.org/c/openstack/nova/+/948087
12:24:34 opendevreview Balazs Gibizer proposed openstack/nova master: Print ThreadPool statistics https://review.opendev.org/c/openstack/nova/+/948340
12:24:35 opendevreview Balazs Gibizer proposed openstack/nova master: Document native threading mode and tuneables https://review.opendev.org/c/openstack/nova/+/949364
12:24:35 opendevreview Balazs Gibizer proposed openstack/nova master: Allow services to start with threading https://review.opendev.org/c/openstack/nova/+/948311
12:24:37 opendevreview Balazs Gibizer proposed openstack/nova master: Run nova-next with n-sch in threading mode https://review.opendev.org/c/openstack/nova/+/948450
12:24:37 opendevreview Balazs Gibizer proposed openstack/nova master: Do not yield in threading mode https://review.opendev.org/c/openstack/nova/+/950994
12:24:39 opendevreview Balazs Gibizer proposed openstack/nova master: Allow to start unit test without eventlet https://review.opendev.org/c/openstack/nova/+/953436
12:24:39 opendevreview Balazs Gibizer proposed openstack/nova master: Run unit test with threading mode https://review.opendev.org/c/openstack/nova/+/953475
12:24:41 opendevreview Balazs Gibizer proposed openstack/nova master: [test]RPC using threading or eventlet selectively https://review.opendev.org/c/openstack/nova/+/953815
12:33:18 opendevreview Balazs Gibizer proposed openstack/nova master: Do not yield in threading mode https://review.opendev.org/c/openstack/nova/+/950994
12:33:19 opendevreview Balazs Gibizer proposed openstack/nova master: Run nova-api and -metadata in threaded mode https://review.opendev.org/c/openstack/nova/+/951957
12:33:19 opendevreview Balazs Gibizer proposed openstack/nova master: Warn on long task wait time for executor https://review.opendev.org/c/openstack/nova/+/952666
12:34:39 opendevreview Balazs Gibizer proposed openstack/nova master: Allow to start unit test without eventlet https://review.opendev.org/c/openstack/nova/+/953436
12:34:39 opendevreview Balazs Gibizer proposed openstack/nova master: Run unit test with threading mode https://review.opendev.org/c/openstack/nova/+/953475
12:34:40 opendevreview Balazs Gibizer proposed openstack/nova master: [test]RPC using threading or eventlet selectively https://review.opendev.org/c/openstack/nova/+/953815
12:34:48 gibi now sign-offs in place :)
12:38:22 opendevreview Kamil Sambor proposed openstack/nova master: Replace eventlet.event.Event with threading.Event https://review.opendev.org/c/openstack/nova/+/949754
12:47:26 sean-k-mooney fungi: there was discssion in the past to remove it a very long time ago, the reason we have kep it is for things like ironic or where you need to use metadata form the config drive to confirgure networkign before you can actully call the metadata api
12:48:01 sean-k-mooney there are also envionment where the metadta api is not deployed
12:48:44 sean-k-mooney or where its in accapble in specific neutron network toplogies like whne you are booted directly to an external network and you are not using ovn or dhcp
12:49:23 fungi yeah, and also (at least currently) no means for the host to signal the location of a network metadata source with non-x86 platforms
12:49:51 sean-k-mooney how does x86 factor into this?
12:50:41 fungi sean-k-mooney: https://bugs.debian.org/1108403
12:50:43 sean-k-mooney is there someting arm or power speciic that woud prevent it doing dhcp adn using the well know adress?
12:51:33 sean-k-mooney ok so that not really nova related its a bug in cloud-init
12:51:52 sean-k-mooney glean or other first boot agenst are not nessiarly impacted right
12:52:01 fungi i have lost access to the more verbose explanation in the (still private) lp bug about how qemu passes information from host to guest that is x86-specific
12:52:48 sean-k-mooney ok but the point is qemu is not ment ot be passign info form the host to the guest in general. config dirve is a way to do that
12:53:40 fungi nova is able to indicate the address of the metadata server through a host-to-guest communication channel when it's x86 platform, but not on other platforms, so cloud-init had a workaround where it just assumed a specific linklocal address, but this was a security problem if booting on other cloud platforms
12:54:42 sean-k-mooney we dont do that however
12:55:03 fungi whatever trick qemu provides for that signalling is specific to emulated x86 systems
12:55:24 sean-k-mooney so im not aware of the mechisim yoru refering too
12:55:28 fungi so cloud-init queries that when run in x86 guests
12:55:47 sean-k-mooney the metaddat discover is ment to be to a hardcoded ip adress in cloud-init or to the defautl gateway as a fall back
12:56:01 fungi really wish they weren't continuing to keep that bug private after referring to it in the commit message of a public security fix
12:56:20 sean-k-mooney to be clear lookign at https://github.com/canonical/cloud-init/commit/f43937f0b462734eb9c76700491c18fe4133c8e1
12:56:26 sean-k-mooney im not even sure that shoudl be a cve
12:56:56 sean-k-mooney but in any case cloud init will use the ec2 well knwo adress in an openstack env

Earlier   Later