| opendevreview | Taketani Ryo proposed openstack/nova master: mem-enc: stop using _get_mem_encryption_config() for SEV checks https://review.opendev.org/c/openstack/nova/+/967970 | 00:28 |
|---|---|---|
| opendevreview | Taketani Ryo proposed openstack/nova master: mem-enc: refactor memory encryption trait logic for extensiblity https://review.opendev.org/c/openstack/nova/+/967971 | 00:28 |
| opendevreview | Taketani Ryo proposed openstack/nova master: mem-enc: make RP creation independent of specific encryption models https://review.opendev.org/c/openstack/nova/+/967972 | 00:28 |
| opendevreview | Taketani Ryo proposed openstack/nova master: mem-enc: refactor _guest_configure_mem_encryption() for extensibility https://review.opendev.org/c/openstack/nova/+/967973 | 00:28 |
| opendevreview | Taketani Ryo proposed openstack/nova master: mem-enc: adjust requirement checks for mem_encryption guests https://review.opendev.org/c/openstack/nova/+/967974 | 00:28 |
| opendevreview | Taketani Ryo proposed openstack/nova master: mem-enc: introduce a check between mem_encryption and locked_memory https://review.opendev.org/c/openstack/nova/+/971300 | 00:28 |
| opendevreview | Taketani Ryo proposed openstack/nova master: mem-enc: refactor memory encryption trait logic for extensibility https://review.opendev.org/c/openstack/nova/+/967971 | 01:03 |
| opendevreview | Taketani Ryo proposed openstack/nova master: mem-enc: make RP creation independent of specific encryption models https://review.opendev.org/c/openstack/nova/+/967972 | 01:03 |
| opendevreview | Taketani Ryo proposed openstack/nova master: mem-enc: refactor _guest_configure_mem_encryption() for extensibility https://review.opendev.org/c/openstack/nova/+/967973 | 01:03 |
| opendevreview | Taketani Ryo proposed openstack/nova master: mem-enc: adjust requirement checks for mem_encryption guests https://review.opendev.org/c/openstack/nova/+/967974 | 01:03 |
| opendevreview | Taketani Ryo proposed openstack/nova master: mem-enc: introduce a check between mem_encryption and locked_memory https://review.opendev.org/c/openstack/nova/+/971300 | 01:03 |
| opendevreview | Merged openstack/nova master: Accept an empty key for addresses https://review.opendev.org/c/openstack/nova/+/978089 | 05:39 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: Remove eventlet from CacheConcurrencyTestCase https://review.opendev.org/c/openstack/nova/+/970069 | 10:59 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: Remove eventlet from libvirt/test_driver https://review.opendev.org/c/openstack/nova/+/970070 | 10:59 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: Remove eventlet from libvirt/volume/test_mount https://review.opendev.org/c/openstack/nova/+/970071 | 10:59 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: Speed up RetryDecorator in unit test https://review.opendev.org/c/openstack/nova/+/975443 | 10:59 |
| r-taketn | I have updated sev refactoring series. However, is merging these changes currently restricted by Feature Freeze? | 11:12 |
| gibi | r-taketn: we reached FF for Gazpacho. One can argure that your series is more of a refactor than a feauture. But I defer to Uggla to decide if we need to wait with your series until master is open for the H cycle | 11:33 |
| r-taketn | Except for the latest patch, I believe this series falls within refactoring. It would be helpful for me to continue the review, but I’ll wait for a decision from Uggla. Thank you for a clarification. | 12:04 |
| opendevreview | Merged openstack/nova master: TPM: fixups for live migration of `host` secret security https://review.opendev.org/c/openstack/nova/+/976316 | 12:04 |
| opendevreview | Merged openstack/nova master: Destroy scatter_gather in conductor https://review.opendev.org/c/openstack/nova/+/977055 | 13:28 |
| *** sambork_ is now known as sambork | 13:36 | |
| nicolairuckel | I'd like to backport my NVRAM patch. Is there any documentation on how to do that? | 13:37 |
| gibi | nicolairuckel: in general backporting bugs are simply. You need to git cherry-pick -x to the youngest stable branch first then when that is done you can cherry-pick from that branch to the next one. Not all patches are accepted as backports on stable. In general we don't allow feature backports, or backports that has external interface impacts like API impacts or DB schema changes. | 13:47 |
| gibi | elodilles: ^^ | 13:47 |
| elodilles | nicolairuckel: what gibi said :) feel free to ping me if you have any further question or need a review for your backport | 13:55 |
| Uggla | gibi, r-taketn, I agree that this series is primarily a refactoring rather than a feature change. | 14:41 |
| Uggla | Given that, I’d prefer we take advantage of the current momentum and continue the review with the goal of merging it during Gazpacho, if possible. This refactoring will also make the upcoming confidential computing work (SEV-SNP and TDX) easier to integrate and reason about. | 14:41 |
| Uggla | So from my side, I’m fine to proceed and not wait for master to reopen for the H cycle. | 14:41 |
| LarsErikP | sean-k-mooney: any more traction here? :P https://review.opendev.org/c/openstack/nova/+/916409 | 14:45 |
| gibi | Uggla: thanks. When r-taketn is back we should clarify with them that then we have an extra two weeks for the refactor | 14:49 |
| opendevreview | Dominik proposed openstack/nova master: NUMA Topology with Resource Providers: Object changes https://review.opendev.org/c/openstack/nova/+/978209 | 14:49 |
| sean-k-mooney | LarsErikP: nope | 14:49 |
| opendevreview | Dominik proposed openstack/nova master: NUMA Topology with Resource Providers: Scheduler changes https://review.opendev.org/c/openstack/nova/+/971176 | 14:50 |
| opendevreview | Dominik proposed openstack/nova master: NUMA Topology with Resource Providers: Libvirt NUMA Migrate https://review.opendev.org/c/openstack/nova/+/971177 | 14:50 |
| opendevreview | Joan Gilabert proposed openstack/nova-specs master: Repropose and update cyborg vGPU (mdev) support https://review.opendev.org/c/openstack/nova-specs/+/967515 | 15:07 |
| opendevreview | Dominik proposed openstack/nova master: NUMA Topology with Resource Providers: Scheduler changes https://review.opendev.org/c/openstack/nova/+/971176 | 15:08 |
| opendevreview | Dominik proposed openstack/nova master: NUMA Topology with Resource Providers: Libvirt NUMA Migrate https://review.opendev.org/c/openstack/nova/+/971177 | 15:11 |
| tkajinam | hmm so nova no longer returns response body and that broke novaclient https://bugs.launchpad.net/python-novaclient/+bug/2142879 | 17:41 |
| opendevreview | Merged openstack/nova master: api: Add ability to filter flavors by name https://review.opendev.org/c/openstack/nova/+/958748 | 17:41 |
| sean-k-mooney | tkajinam: that is intentional i think the api is now async | 17:43 |
| sean-k-mooney | tkajinam: i didnt review the patch much but i belive the schema for 2.101 states the body shoudl be empty | 17:44 |
| tkajinam | I'm still confused because https://review.opendev.org/c/openstack/nova/+/971068/9/api-ref/source/os-volume-attachments.inc#109 says the body should be empty but | 17:44 |
| tkajinam | oh. wait. I see. | 17:45 |
| sean-k-mooney | heat need to be modifyed to supprot 2.101 it shoudl not be useing latest blindly | 17:45 |
| tkajinam | but I'm wondering how the volume attachment should be monitored then ? | 17:45 |
| tkajinam | I mean we don't know which record is exactly being created | 17:45 |
| sean-k-mooney | i dont recall the spec off hand https://github.com/openstack/nova-specs/blob/master/specs/2026.1/approved/async-volume-attachments.rst | 17:46 |
| sean-k-mooney | but it shoudl cover that | 17:47 |
| sean-k-mooney | my guess is via the instance action events? | 17:47 |
| sean-k-mooney | i.e. use the reqeust id to identify the instnace action event and wait for it to be complete | 17:48 |
| sean-k-mooney | althogh your aware of the exisitng bug with that flow | 17:48 |
| sean-k-mooney | so the only relyable way | 17:48 |
| sean-k-mooney | woudl be to watch the volume via nova show | 17:48 |
| sean-k-mooney | the volume wont be listed in the show responce until its attached i belive | 17:49 |
| sean-k-mooney | but again i didnt really review this in detail | 17:49 |
| gmaan | yes, it will not return attachment response, it will return 202 only like other asyn API | 17:50 |
| gmaan | I am reviewing the tempest change which is good way to see what all changed - https://review.opendev.org/c/openstack/tempest/+/977952 | 17:50 |
| tkajinam | so is there any plan to fix novaclient ? | 17:51 |
| tkajinam | I can update heat to adopt to the change but the create_server_volume API is just broken | 17:51 |
| tkajinam | with 2.101 | 17:51 |
| sean-k-mooney | no | 17:51 |
| gmaan | I think novaclient use latest microversion so that is expected behaviour | 17:51 |
| sean-k-mooney | nova client is frozen for both python and cli usage | 17:51 |
| gmaan | yeah | 17:51 |
| sean-k-mooney | it does not suprpot anythign over 2.96 i think | 17:51 |
| tkajinam | do you mean that ugly TypError is expected ? | 17:51 |
| sean-k-mooney | tkajinam: nova client hsoudl not be used with any microveron beyond its max verion | 17:52 |
| gmaan | ohk if it is TypeError then yes it is broken but it should be fixed in osc if there too it is broken | 17:52 |
| gmaan | stephenfin: did not officially deprecated that? | 17:53 |
| tkajinam | sean-k-mooney, do you know where that max version is defined ? | 17:53 |
| sean-k-mooney | its in the client code one sec | 17:53 |
| tkajinam | novaclient/__init__.py:API_MAX_VERSION = api_versions.APIVersion("2.96") | 17:53 |
| tkajinam | ok | 17:53 |
| sean-k-mooney | yep ^ | 17:53 |
| gmaan | tkajinam: https://github.com/openstack/python-novaclient/blob/e00ed698af04e2c5b78db3516d26c79ffed9851f/novaclient/__init__.py#L28 | 17:53 |
| sean-k-mooney | tkajinam: that why we move watcher to the sdk this cycle for what its worth | 17:54 |
| gmaan | then why it is broken? and how it requested with 2.101? | 17:54 |
| sean-k-mooney | gmaan: novaclient does nto clamp internally | 17:54 |
| sean-k-mooney | but this i htink is more of a heat bug in that heat should nto just be using latest | 17:54 |
| sean-k-mooney | it shoudlbe passing the expected micoverion for each call | 17:55 |
| gmaan | i see, got it. maybe we should through error if requested with >2.96 | 17:55 |
| gmaan | that will be more explicit | 17:55 |
| sean-k-mooney | to get the behvior it is coded to supprot | 17:55 |
| tkajinam | https://opendev.org/openstack/heat/src/commit/f110fc56492022f71b38a882c9a1ea60ba4da6d4/heat/engine/clients/os/nova.py#L95-L105 | 17:57 |
| sean-k-mooney | that looks ok its the call site where your actully doing the attachment that is likely incorrect | 17:58 |
| sean-k-mooney | https://opendev.org/openstack/heat/src/commit/f110fc56492022f71b38a882c9a1ea60ba4da6d4/heat/engine/clients/os/nova.py#L684-L701 | 17:59 |
| sean-k-mooney | i dont see a microverison being spcifed there | 18:00 |
| tkajinam | in heat we use common microversion for all api calls | 18:00 |
| sean-k-mooney | ya that is entirly broken | 18:00 |
| tkajinam | and the version is detected by API call. by default is uses the latest one available | 18:00 |
| sean-k-mooney | that is not somethign that applciation can or shoudl ever do | 18:01 |
| tkajinam | I'll update heat to cap the version according to the version defined there | 18:01 |
| sean-k-mooney | its also not safe to do in general | 18:01 |
| gmaan | yeah, microversion does not provide backward compatible, it needs to be on opt basis instead of latest by default | 18:02 |
| tkajinam | it might be ideal to define expected api version for each call, though I don't know if that's really feasible for people to check every single microversion and check whether any single call can be bumped | 18:02 |
| tkajinam | given we have 100+ versions now | 18:02 |
| sean-k-mooney | well that is how our api contract is defiend | 18:02 |
| sean-k-mooney | we add a new microverion if we change behvior and keep the old micoverion workign the way they always didi | 18:02 |
| tkajinam | I know, though I sometimes wonder if we can consider bumping "min supported" version several years after 2.2 was created | 18:07 |
| sean-k-mooney | i am not agaisnt that but where i woudl like to bump to an other woudl differ widely | 18:08 |
| sean-k-mooney | tkajinam: heat can | 18:08 |
| sean-k-mooney | indepnetn of nova | 18:08 |
| dansmith | melwitt: can we not pull the "enable conversion of secret modes" down in the stack and try to get it merged? | 18:10 |
| dansmith | I guess maybe too late for FF | 18:12 |
| tkajinam | I'll see if https://review.opendev.org/c/openstack/heat/+/978246 works | 18:13 |
| tkajinam | there've been a few other problems I had to fix before I eventually encountered this. This cycle has been too exciting... | 18:14 |
| opendevreview | Merged openstack/nova master: TPM: bump service version to enable live migration https://review.opendev.org/c/openstack/nova/+/975724 | 18:21 |
| stephenfin | sean-k-mooney: tkajinam: wait, what's broken? | 18:37 |
| * stephenfin is trying to grok the scrollback but there's a lot :) | 18:37 | |
| gmaan | stephenfin: support of 2.101 in novaclient where it can handle the no response from volume attachment API | 18:37 |
| gmaan | I will say it is not broken but not supported as planned | 18:40 |
| sean-k-mooney | Uggla: https://meetings.opendev.org/irclogs/%23openstack-release/latest.log.html#openstack-release.2026-02-27.log.html#t2026-02-27T18:59:45 the change to python-novaclint to move it to indemepent and stop branching it from antelop has been implemtned in the release tooling | 19:07 |
| opendevreview | Stephen Finucane proposed openstack/python-novaclient master: Add version foot protector https://review.opendev.org/c/openstack/python-novaclient/+/978254 | 19:16 |
| stephenfin | gmaan: sean-k-mooney: tkajinam: ^ | 19:16 |
| stephenfin | I think that's a reasonable change | 19:17 |
| stephenfin | sean-k-mooney: my understanding (which that mail backs up) was that we were not adding support any more microversions but we would fix bugs | 19:17 |
| stephenfin | *support for | 19:17 |
| sean-k-mooney | and woudl only fix them on master no more relases :P | 19:19 |
| sean-k-mooney | lookign at the history however the change to move it to indepentne and to sotp the brancches being created that we agreed for antelop was not actully implemnted | 19:19 |
| stephenfin | that mail says nothing about not cutting releases 😅 | 19:19 |
| stephenfin | > we agreed on changing the release model for novaclient to be independent so we can release anytime we need. | 19:20 |
| stephenfin | that says the opposite ☝️ | 19:20 |
| sean-k-mooney | we also had ptg dicsusion after that | 19:20 |
| sean-k-mooney | there was nto ment ot be any automatic release | 19:20 |
| sean-k-mooney | only as needed bugfix ones | 19:20 |
| sean-k-mooney | so no automatic release at milestone 1 and rc1 | 19:21 |
| stephenfin | that's fine, but that's not what I'm arguing | 19:21 |
| stephenfin | I'm saying we can still cut releases. Whether they're automatic or not is a separate point | 19:21 |
| stephenfin | the antelope PTG etherpad is here https://etherpad.opendev.org/p/nova-antelope-ptg and it says: | 19:23 |
| stephenfin | > we don't want to deprecate novaclient bindings as we're willing to continue supporting feature parity between SDK and novaclient as operators/heat/whatever continue to use novaclient and don't have resources to make a big leap to SDK. | 19:23 |
| stephenfin | that sounds like bauzas wording :) | 19:23 |
| stephenfin | no, it's me actually | 19:23 |
| sean-k-mooney | yep. since then we have had a pamdemic and the rise of our llm overlords | 19:24 |
| sean-k-mooney | well the latter that was in 2022 | 19:25 |
| sean-k-mooney | not the former | 19:25 |
| sean-k-mooney | anyway the patch looks ok | 19:25 |
| sean-k-mooney | im reading it again to be sure | 19:25 |
| sean-k-mooney | so you decied to raise if its over the max supproted by the lib instead of clamp | 19:27 |
| sean-k-mooney | i guess that is safer | 19:27 |
| sean-k-mooney | althoguh clampign to 2.96 for client that used latest woudl still be semanticly valid | 19:27 |
| stephenfin | I think so. Heat still needs to make changes but at least they'll fail immediately | 19:27 |
| stephenfin | I thought about that, but if users says do X I don't think I should silently swap in Y | 19:28 |
| sean-k-mooney | ok ill make a note but im not agisnt that propsoal | 19:28 |
| stephenfin | subtest is awsome too. table-driven tests are one of Go's better ideas | 19:29 |
| sean-k-mooney | actully | 19:30 |
| sean-k-mooney | we have code in the verison negoication to do that already | 19:30 |
| sean-k-mooney | https://github.com/openstack/python-novaclient/blob/master/novaclient/api_versions.py#L307-L308 | 19:31 |
| sean-k-mooney | if you use discover_version(client, requested_version) | 19:31 |
| sean-k-mooney | ti will try to do the right thing | 19:31 |
| opendevreview | Zhan Zhang proposed openstack/nova master: Change live_migration_downtime_delay to float https://review.opendev.org/c/openstack/nova/+/978255 | 19:54 |
| opendevreview | Zhan Zhang proposed openstack/nova master: Change live_migration_downtime_delay to float https://review.opendev.org/c/openstack/nova/+/978255 | 19:59 |
| melwitt | dansmith: yeah I had assumed there wouldn't be enough time for the conversion one. but it's also only needed for converting to user/host from deployment or deployment to user/host and we didn't merge live migration of 'deployment' yet | 20:05 |
| dansmith | yeah I'm a bit confused about user->host, see my comment | 20:05 |
| melwitt | yeah I'm looking through your review comments. tl;dr is there is no conversion needed for user -> host or vice versa because those both have a user-owned secret. nova service user is not the secret owner | 20:07 |
| dansmith | right, but .. oh, maybe just the act of the resize will stab it into libvirt on the destination host as ephemeral=false? | 20:08 |
| melwitt | the conversion is only if you are looking to go from a user owned secret to a nova service user owned secret or vice versa. and the logic I used for that is "side-by-side" until revert or confirm | 20:08 |
| melwitt | yeah it's just the metadata that will make it create it with the right properties | 20:08 |
| melwitt | it's "automatic" | 20:08 |
| dansmith | " These two steps will be done automatically during _create_guest(), so nothing needs to be done here." derp | 20:09 |
| dansmith | okay sorry I missed that ^ and was expecting to see something but yeah, makes sense | 20:09 |
| dansmith | so, erm, what happens in resize-to-same-host? | 20:09 |
| melwitt | the complicated thing is if you have a user owned secret (user or host) and resize wants to go to 'deployment'. so the logic I used is, keep the existing secret and create a NEW nova service user owned secret with the same passphrase (string) and then based on confirm or revert delete the one we no longer need | 20:10 |
| dansmith | yeah, I understand the to/from deployment complexity | 20:10 |
| melwitt | resize to same host still involves destroy/create guest domain I assume, so it works the same way | 20:11 |
| dansmith | okay | 20:11 |
| melwitt | the libvirt secret lifecycle matches the domain lifecycle, I think. (I will double check all of it). so it is sort of "regularly" destroyed and recreated | 20:12 |
| dansmith | melwitt: yeah, yeah, okay | 20:12 |
| dansmith | so is my complaint about the test not actually asserting the secret ephemeral-ness still valid? | 20:12 |
| melwitt | I haven't read all of them yet but I will check | 20:13 |
| dansmith | if it was doing that, I would have known that I was (indeed) missing something.. well, I'd like to think I would :) | 20:13 |
| dansmith | I went looking at the tests to see if you were covering that case when I didn't see ->host and didn't see any such assertion | 20:13 |
| melwitt | I can't remember if ephermeral-ness is/can be asserted in the func tests. I have those assertions in the whitebox tests but I need to remind on the func tests | 20:15 |
| opendevreview | melanie witt proposed openstack/nova master: testing: Run functional tests under [testenv:cover] https://review.opendev.org/c/openstack/nova/+/975346 | 20:39 |
| sean-k-mooney | for what its worth we discussed doing ^ in the past and ever got aroudn to it | 21:04 |
| sean-k-mooney | one of the open question was if we wanted to have it be 2 targets or just one | 21:05 |
| sean-k-mooney | but i didnt really have a prefence either way | 21:05 |
| rm_work[m] | Hey, we're having trouble with nova (2025.2) and using TLS DB connection (I believe that's what is causing this error, at least): https://paste.opendev.org/show/booEwPakhOsPuP7Ws5Ul/ | 21:18 |
| rm_work[m] | is this a known issue? or maybe I have the root cause wrong | 21:18 |
| gmaan | melwitt: finished the vtpm tempest test review, do you have devstack change or nova job change where it is enabled and tests running https://review.opendev.org/c/openstack/tempest/+/957475 | 21:19 |
| gmaan | ah got it, this one https://review.opendev.org/c/openstack/nova/+/957477 | 21:20 |
| melwitt | yep you got it, thanks for looking | 21:21 |
| gmaan | are you planning to remove the DNM from it? bcz before merging tempest tests, we need at least one job that run those tests | 21:24 |
| melwitt | gmaan: yeah I need to do that also | 21:27 |
| gmaan | ack, thanks | 21:27 |
| gmaan | I will check the whitebox test later in evening or on Monday | 21:31 |
| sean-k-mooney | rm_work[m]: that issue is form eventlet/greenlet depending on the version you are using it might be a know issue that was resolved. there were a few errors like that but i dont recall off the top of my head exactly hwen they were fixed. ill note that nova does not test with gunicorn so while it should work if you run it in eventlt mode | 21:51 |
| sean-k-mooney | i.e. gunicorn myapp:app -k eventlet --worker-connections 1000 | 21:51 |
| rm_work[m] | ok well I discovered export OS_NOVA_DISABLE_EVENTLET_PATCHING=true lol | 21:52 |
| rm_work[m] | seems to work mostly on 2025.2 | 21:52 |
| rm_work[m] | oh I didn't realize it also needed eventlet mode <_< | 21:52 |
| sean-k-mooney | we implment scater gatther for some api request that go across multiple cells | 21:53 |
| sean-k-mooney | that is the only thing that uses it in the api | 21:53 |
| sean-k-mooney | but ya you could swap to the non eventlet backens for grunicorn | 21:54 |
| rm_work[m] | hmmm worker-class eventlet doesn't seem to help | 21:55 |
| rm_work[m] | so yeah am trying with no eventlet | 21:55 |
| rm_work[m] | will just switch to 2026.1 as soon as it's released too heh | 21:55 |
| rm_work[m] | tempted to rebuild all our stuff on master <_< but some pushback from above heh | 21:55 |
| sean-k-mooney | if you do let use know how it goes | 21:56 |
| sean-k-mooney | yesterday we meged the ablity to run nova-compute without eventlet | 21:56 |
| rm_work[m] | did notice some cells issues possibly, digging in first before I say anything concrete | 21:56 |
| rm_work[m] | looks like the issue is nova not supporting a comma-separated RMQ transport URL for multiple RMQs? do we need to use a loadbalancer or a single RMQ? | 22:01 |
| sean-k-mooney | there si a wasy to use multiple server but we recommend a loadblancer | 22:02 |
| rm_work[m] | ok | 22:02 |
| rm_work[m] | for reference: https://paste.opendev.org/show/b9nwUz4doBA2Kd97rcBs/ | 22:02 |
| sean-k-mooney | driver://[user:pass@]host:port[,[userN:passN@]hostN:portN]/virtual_host?query | 22:03 |
| sean-k-mooney | its like that | 22:03 |
| sean-k-mooney | rabbit://rabbitmq:password@127.0.0.1:5672,rabbitmq:password@127.0.0.2:5672/? | 22:05 |
| sean-k-mooney | you do not repeat the schema part just the user/password/host/port part | 22:06 |
| sean-k-mooney | https://docs.openstack.org/oslo.messaging/latest/reference/transport.html | 22:06 |
| sean-k-mooney | this is just direclty form oslo | 22:06 |
| rm_work[m] | hmmm i think we do that already | 22:08 |
| rm_work[m] | rabbit://openstack-rabbitmq-server-0.openstack-rabbitmq-nodes.infra.svc.cluster.local:5671,openstack-rabbitmq-server-1.openstack-rabbitmq-nodes.infra.svc.cluster.local:5671,openstack-rabbitmq-server-2.openstack-rabbitmq-nodes.infra.svc.cluster.local:5671/nova | 22:08 |
| rm_work[m] | seems to match | 22:08 |
| rm_work[m] | we use TLS so no user/pass | 22:08 |
| rm_work[m] | it's having issues splitting in the cells side | 22:08 |
| rm_work[m] | see the paste | 22:09 |
| sean-k-mooney | i thin the user is requried | 22:09 |
| rm_work[m] | hmmmm | 22:09 |
| sean-k-mooney | although im not sure | 22:09 |
| rm_work[m] | it works with other services | 22:10 |
| rm_work[m] | tracking down the exact line on the nova side, one sec | 22:10 |
| sean-k-mooney | https://docs.openstack.org/nova/latest/admin/cells.html#template-urls-in-cell-mappings | 22:10 |
| sean-k-mooney | that is the docs for the cell specific part | 22:10 |
| rm_work[m] | I think https://opendev.org/openstack/nova/src/branch/stable/2025.2/nova/objects/cell_mapping.py#L100 is just trying to parse the whole URL without splitting | 22:10 |
| rm_work[m] | but trying to trace backwards | 22:10 |
| rm_work[m] | reading your doc quick now | 22:10 |
| sean-k-mooney | i think to make it work in the cell mappign you have to use the template url syntax | 22:11 |
| sean-k-mooney | but the only instlal i knowof that used that or multipel hosts was tripleo | 22:12 |
| sean-k-mooney | so i have evictine dmost of my understanding of how that works | 22:12 |
| sean-k-mooney | all the rest just used haproxy | 22:12 |
| rm_work[m] | hmmm ok looking, not clear on how to put the other hostnames in that template, or if that even really gives us multiple | 22:12 |
| sean-k-mooney | in the template you dont | 22:13 |
| sean-k-mooney | in teh transport url you do but in the template you only have one host | 22:13 |
| rm_work[m] | yeah ok so LB it is prolly, since we expect these may individually go down due to like k8s evictions/etc | 22:14 |
| sean-k-mooney | "rabbit://{hostname}:{port}/{path}?{query}" | 22:14 |
| sean-k-mooney | somethign like that | 22:14 |
| rm_work[m] | will try with ServiceIP but I think that causes other issues and is not the recommended way to deploy per the RMQ folks | 22:14 |
| sean-k-mooney | our new downstram installer just use meltallb | 22:15 |
| rm_work[m] | hmm yeah we have that available | 22:18 |
| rm_work[m] | this is odd though, seems like it should be working, so idk what's going on. will keep digging. | 22:21 |
| opendevreview | melanie witt proposed openstack/nova master: unified limits: Fix openstacksdk usage for endpoint discovery https://review.opendev.org/c/openstack/nova/+/975106 | 22:23 |
| sean-k-mooney | rm_work[m]: im not aware of anything changing related to that recently in any case. | 22:31 |
| rm_work[m] | yeah i was digging backwards and also see no changes | 22:32 |
| rm_work[m] | but I don't really understand how this could ever have worked | 22:32 |
| sean-k-mooney | as i said i think ye must have been usign a template url and only had the multipel servers in the nova.conf rather then in the cell mappings | 22:36 |
| sean-k-mooney | since i think that is the only way that ever worked | 22:37 |
| opendevreview | melanie witt proposed openstack/nova master: testing: Run functional tests under [testenv:cover] https://review.opendev.org/c/openstack/nova/+/975346 | 23:52 |
| melwitt | stephenfin, dansmith: reverted back to PS2 and increased job timeout to 4200 seconds for a little more head room. it seemed like weird errors were happening when stestr runs unit and func tests concurrently | 23:54 |
| melwitt | ^ | 23:54 |
Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!