| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-06-30 | |||
| 13:04:12 | sean-k-mooney | im late for a meeting but ill be free in an hour and can look into this more | |
| 13:04:47 | zigo | We do, it just need a specific metadata. | |
| 13:05:18 | zigo | As much as my colleague is telling me, this would *not* break our windows image that has the virtio CD support. | |
| 13:05:38 | zigo | hw_cdrom_bus=virtio | |
| 13:05:38 | zigo | the metadata is: | |
| 13:05:39 | sean-k-mooney | will it break a vanilla windows install iso | |
| 13:05:47 | sean-k-mooney | zigo: so you can set that | |
| 13:05:55 | zigo | *we* wouldn't care. | |
| 13:05:56 | sean-k-mooney | but there used to be problems with useing it | |
| 13:06:03 | sean-k-mooney | well nova would | |
| 13:06:39 | zigo | sean-k-mooney: Yeah, *we* can, but some idiot customers have no idea about it, will take system image snapshot or backup, attempt to boot, and see it fail because of the CD being ide and the lack of AHCI support in the image. | |
| 13:06:45 | zigo | I'd like to avoid this ... | |
| 13:07:37 | sean-k-mooney | so we really try to not make things dynmaic based on the image in a lot of cases but its worth a dicussion at least | |
| 13:07:47 | opendevreview | Takashi Kajinami proposed openstack/nova master: sqlalchemy: Use built-in declarative https://review.opendev.org/c/openstack/nova/+/953751 | |
| 13:07:57 | sean-k-mooney | zigo: i know there was a reason we could not use virtio as the default at the time | |
| 13:08:02 | sean-k-mooney | but i dont recall the details | |
| 13:08:10 | sean-k-mooney | it may have been our min libnvirt versin at the time | |
| 13:09:35 | sean-k-mooney | zigo: i assume you woudl prefer that we use virio by default both for pc and q35 machine type? | |
| 13:12:15 | sean-k-mooney | zigo: the last time we chagne defautl was yoga https://blueprints.launchpad.net/nova/+spec/virtio-as-default-display-device | |
| 13:12:24 | sean-k-mooney | so we have precendet for doing this | |
| 13:13:29 | opendevreview | Takashi Kajinami proposed openstack/placement master: sqlalchemy: Use built-in declarative https://review.opendev.org/c/openstack/placement/+/953759 | |
| 13:54:29 | stephenfin | sean-k-mooney: gibi: ralonsoh: I assume you're aware that nova-ovs-hybrid-plug is permafailing on master since last Friday? https://zuul.opendev.org/t/openstack/builds?job_name=nova-ovs-hybrid-plug&project=openstack/nova | |
| 13:54:46 | ralonsoh | let me check | |
| 13:55:08 | stephenfin | I took a look at things that merged to neutron and neutron-lib between the last pass and first fail but didn't spot anything obvious | |
| 13:55:38 | stephenfin | ralonsoh: neutron-api is failing because there's a name field being set on a model that doesn't have the relevant column | |
| 13:56:00 | stephenfin | https://zuul.opendev.org/t/openstack/build/79bd7dae1b954169a77159ca53b85422/log/controller/logs/screen-neutron-api.txt | |
| 13:56:34 | stephenfin | (specifically the networksegments table as you'll se) | |
| 13:56:35 | stephenfin | *see | |
| 13:56:49 | ralonsoh | let me check first the last patches merged | |
| 14:02:06 | ralonsoh | stephenfin, this is because a stupid guy merged a patch last friday | |
| 14:02:15 | ralonsoh | a very stupid guy and a very stupid patch | |
| 14:02:20 | gibi | sean-k-mooney: dansmith: could you add the back the +A to https://review.opendev.org/c/openstack/nova/+/948072/ it was lost in a rebase | |
| 14:03:08 | dansmith | done | |
| 14:03:19 | ralonsoh | stephenfin, I've pushed the fix: https://review.opendev.org/c/openstack/neutron/+/953768. Check that the Neutron db migration is failing: https://zuul.opendev.org/t/openstack/build/46c6d08486c3461dbc6f3fcb3c2b832d/log/job-output.txt#13491 | |
| 14:03:24 | stephenfin | ralonsoh: :D | |
| 14:03:26 | gibi | dansmith: thanks | |
| 14:04:27 | stephenfin | ahh | |
| 14:04:35 | stephenfin | I was looking in the wrong place | |
| 14:05:18 | stephenfin | ralonsoh: Looks like a bug in devstack too. init_neutron shouldn't be finishing with result 0 if the db_sync failed, right? https://zuul.opendev.org/t/openstack/build/46c6d08486c3461dbc6f3fcb3c2b832d/log/job-output.txt#13509 | |
| 14:05:40 | ralonsoh | right, that should have been stopped the stack process | |
| 14:09:50 | opendevreview | ribaudr proposed openstack/nova-specs master: Enable memfd support for shared memory backing https://review.opendev.org/c/openstack/nova-specs/+/951689 | |
| 14:11:45 | Uggla | sean-k-mooney, gibi, dansmith if you have time I'll be happy it you can have a look at ^ | |
| 14:41:26 | zigo | sean-k-mooney: I'd prefer if it was virtio-cd *always*, yes. | |
| 14:41:50 | sean-k-mooney | so if we were to make that change it would only take effect for new vms | |
| 14:42:15 | zigo | Yeah, I get that point. | |
| 14:42:23 | sean-k-mooney | when we made teh other changes we added code to recored the currnt model in the db | |
| 14:42:32 | sean-k-mooney | we did that so we could chagne the default in the future | |
| 14:43:31 | zigo | BTW. what is the use of rabbit_qos_prefetch_count? I've set use_queue_manager and rabbit_stream_fanout, but now nova-compute complains I haven't set rabbit_qos_prefetch_count and it is to its default of zero. What is a good value for this then ? | |
| 14:43:38 | sean-k-mooney | we bassically pretent the glance image properlty is set and add it in isntance sysmtem metaadat table as if it came form teh glance image when the vm is first created | |
| 14:44:07 | sean-k-mooney | zigo: no idea i dont think we sue that in nvoa today so its proably directly coming form oslo.messaging | |
| 14:44:55 | sean-k-mooney | zigo: we directly include the oslo.messaging cofnig options in our config because all the parsieng fo those exctra are done by oslo not nova | |
| 14:45:07 | zigo | Yeah, like everyone else does! :) | |
| 14:45:26 | sean-k-mooney | well excpet swift... | |
| 14:45:52 | zigo | Which is a real pain. | |
| 14:46:14 | zigo | We tried switching to json log to send all to Elasticsearch, it worked great ... except for swift ! :/ | |
| 14:46:22 | sean-k-mooney | so i am not sure what that does but you might get a better answer for the oslo folks | |
| 14:46:43 | sean-k-mooney | zigo: i both love and hate that that exists | |
| 14:46:51 | sean-k-mooney | its really nice for suecase like that | |
| 14:47:12 | sean-k-mooney | but when our custoerm enabel that and i have to ready the raw logs in json format it sucks | |
| 14:47:44 | sean-k-mooney | i wish there was a tool to take teh json format and print them normally in human reablae forrmat in oslo | |
| 14:47:46 | zigo | It was commited together with the fanout and stream stuff by Arnaud Morin <arnaud.morin@ovhcloud.com> | |
| 14:47:54 | zigo | https://review.opendev.org/c/openstack/oslo.messaging/+/890825 | |
| 14:48:00 | sean-k-mooney | ya so nova does not supprot any of that offically | |
| 14:48:01 | zigo | Though absolutely no doc about it ... :/ | |
| 14:48:28 | sean-k-mooney | im vagly aware that stream supprot has been added but no work has been doen to use nova with it | |
| 14:48:41 | sean-k-mooney | it might work but no one has done the work to test it | |
| 14:48:55 | zigo | https://www.rabbitmq.com/docs/consumer-prefetch | |
| 14:48:58 | sean-k-mooney | there has been no cross project work to support it that im aware off | |
| 14:49:46 | sean-k-mooney | ok so it sound like itx a limit of how many unacked message a clinet can have at a time | |
| 14:51:53 | sean-k-mooney | https://bugs.launchpad.net/oslo.messaging/+bug/2031497 really shoudl have had an oslo spec IMO | |
| 14:52:12 | sean-k-mooney | maybe they had one for stream supprot in general | |
| 14:52:24 | zigo | Agreed. | |
| 14:52:52 | sean-k-mooney | zigo: i hope your not plannig to use that in debian 13 by default | |
| 14:53:04 | sean-k-mooney | the stream supprot i mean | |
| 14:53:49 | sean-k-mooney | its disabled by default in oslo https://docs.openstack.org/nova/latest/configuration/config.html#oslo_messaging_rabbit.rabbit_stream_fanout | |
| 14:53:58 | sean-k-mooney | and we do not ahve any testing with it at all for nova | |
| 14:54:26 | sean-k-mooney | we also do not test with rabbit_quorum_queue set to ture either | |
| 14:54:40 | sean-k-mooney | it might work but again no work has been doen in nova to offically supprot it | |
| 14:55:09 | sean-k-mooney | we could close that gap by enablign testing in nova-next | |
| 14:55:23 | zigo | Well, it's time to move to it: rabbitmq does *not* support HA queue starting at version 4.0.x | |
| 14:55:28 | zigo | So no choice for operators. | |
| 14:55:30 | sean-k-mooney | but we would also need to update the docs before offically supproting it | |
| 14:55:56 | sean-k-mooney | im aware although flamingo is the first realee we are usign 4.0.0 i think | |
| 14:56:03 | sean-k-mooney | although that may have been epoxy | |
| 14:56:16 | sean-k-mooney | it depend on what is in ubuntu 24.04 | |
| 14:56:20 | zigo | Ahh... Please everyone: stop that bullshit again. Upstream does not get to choose what's in the distro. :( | |
| 14:56:34 | sean-k-mooney | we get to choose what we supprot | |
| 14:56:47 | sean-k-mooney | and if we dont have it aviabel in our ci to test with we cant claim supprot | |
| 14:56:50 | zigo | Debian Trixie has RabbitMQ 4.0.5, and it has Epoxy. | |
| 14:57:00 | sean-k-mooney | ack | |
| 14:57:17 | zigo | Just like I have to make Epoxy run on Python 3.13: no choice... :/ | |
| 14:57:18 | sean-k-mooney | i think its goign to be imporant to get trixy in our ci as soon as practical | |
| 14:57:30 | sean-k-mooney | we offically only supprot debian 12 cuyrrently | |
| 14:57:36 | zigo | I need to fix this rabbitmq config first, so I can continue my tests. | |
| 14:57:38 | sean-k-mooney | trixy woudl be add next cycle | |
| 14:58:03 | zigo | Trixie is out in a few weeks... :) | |
| 14:58:05 | sean-k-mooney | ack, i think must of those feature are aviabel in the older release of rabbit too | |
| 14:58:21 | sean-k-mooney | so we can try and use them in our existing jobs provide they work | |
| 14:58:22 | zigo | It's always the same story anyways, so I'm used to it. :) | |
| 16:36:09 | gmaan | sean-k-mooney: you might have noticed but pinging just in case you missed that manager role series is ready for review https://review.opendev.org/q/topic:%22bp/policy-manager-role-default%22+status:open | |