| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-12-11 | |||
| 15:40:39 | noonedeadpunk | heh, "few":) | |
| 15:41:47 | noonedeadpunk | ok, so eventually cells are super good for EDGE I assume | |
| 15:42:25 | sean-k-mooney | am it depends. | |
| 15:42:39 | sean-k-mooney | for far edge you dont want to have 1 cell per store | |
| 15:43:01 | sean-k-mooney | but for near edge it can be a good toplogy | |
| 15:44:07 | noonedeadpunk | ok, so back to the confusion I have... what is the difference in config between conductor and super conductor? Just presence of api_database? | |
| 15:45:32 | sean-k-mooney | the rabbit transport url and api_databases section | |
| 15:48:02 | noonedeadpunk | ok, but where do I define cell transport then? or cell conductor has cell rabbitmq in transport_url and super conductor has cell0 transport_url? | |
| 15:48:22 | sean-k-mooney | yes that ^ | |
| 15:48:43 | noonedeadpunk | and then super conductor finds out about cells from api_database and connects there as well? | |
| 15:49:18 | sean-k-mooney | when it needs to yes | |
| 15:49:59 | noonedeadpunk | and then superconductor does not have [database] section at all I assume? | |
| 15:50:24 | sean-k-mooney | no it has the cell 0 db | |
| 15:50:44 | noonedeadpunk | but isn't that api_database? | |
| 15:50:51 | sean-k-mooney | no | |
| 15:51:11 | noonedeadpunk | ok, I need to check on that then... | |
| 15:51:18 | sean-k-mooney | a default "single cell" cellv2 deployment has 3 databases | |
| 15:51:29 | sean-k-mooney | nova_api nova_cell0 and nova_cell1 | |
| 15:51:48 | sean-k-mooney | the cell dbs have the same schema | |
| 15:51:52 | sean-k-mooney | the api db is differnt | |
| 15:51:55 | noonedeadpunk | hm, I think we have 2.... | |
| 15:52:14 | noonedeadpunk | oh, right | |
| 15:52:35 | noonedeadpunk | jsut nova_cell0 is not really used in "single" setup | |
| 15:52:50 | sean-k-mooney | its special it will never have comptues | |
| 15:53:31 | sean-k-mooney | it does hold things like service record ectra | |
| 15:53:59 | sean-k-mooney | but it will thend to have littel data beyond isntnaces that failed to schdule | |
| 15:54:53 | noonedeadpunk | but in "single cell" setup, there's actually nothing which could connect to cell0? | |
| 15:55:07 | sean-k-mooney | i woudl suggest lookign at the video links in https://docs.openstack.org/nova/latest/admin/cells.html#references to undersand hwo this is intended to work | |
| 15:55:36 | sean-k-mooney | in your single cell case the api can and does | |
| 15:56:05 | noonedeadpunk | yeah, I was trying to think if that's possible to do without superconductor, by allowing all cell conductors to connect to api database/mq | |
| 15:56:06 | sean-k-mooney | the conductor can and does via lookign it up in the db if it needs too | |
| 15:56:59 | noonedeadpunk | and avoid need to have a "special" superconductor | |
| 15:58:06 | sean-k-mooney | yes but that is not somethign you shoudl do | |
| 15:58:40 | sean-k-mooney | the primary reason to have multipel cells is to scale nova by shardign it db and rabbit clusters | |
| 15:58:48 | noonedeadpunk | I was thinking if that could solve trade-offs with upcalls | |
| 15:59:00 | sean-k-mooney | no it does not help | |
| 16:00:01 | noonedeadpunk | yeah, so each cell has own db and mq, where main load is handled, but then all conductors would connect to this db, which might be an option if you have like couple of cells | |
| 16:00:16 | sean-k-mooney | this was one fo the things tripleo got very wrong when they first added the ablity to add an addtional cell | |
| 16:00:34 | noonedeadpunk | okay, gotcha | |
| 16:06:49 | noonedeadpunk | I guess next part is - how that is working with AZs.... | |
| 16:07:07 | sean-k-mooney | compeltely unerlated concepts | |
| 16:07:39 | noonedeadpunk | but like... it would make sense to have cell per az? | |
| 16:07:52 | sean-k-mooney | hosts in a cell can be in diffent AZs and AZ can refence hosts in multiple cells | |
| 16:08:22 | sean-k-mooney | noonedeadpunk: that is one apprch but it depend on your usecase | |
| 16:08:32 | sean-k-mooney | its not forced in anyway | |
| 16:08:50 | noonedeadpunk | as given AZ is geographically spread, having mariadb/rabbitmq cluster isolated in it - makes sense | |
| 16:09:18 | sean-k-mooney | AZ in openstack have many uses that is only one of them | |
| 16:09:28 | noonedeadpunk | oh right, sure | |
| 16:09:47 | sean-k-mooney | remember that AWS aviablity zone are a better logical map to a keystone region then they are to a nova AZ | |
| 16:10:33 | noonedeadpunk | right, though what we are trying to do, is to have stretched tenant networks between AZs | |
| 16:10:54 | sean-k-mooney | again cells are for scaling. if you scaling unit happend to be a dataceneter and each datacenter is phsycial spreand then 1 cell per datacenter and one AZ per data ceneter might make sense | |
| 16:10:57 | noonedeadpunk | and have workloads stretched as well, which you can not do easily with different regions | |
| 16:11:10 | noonedeadpunk | yup | |
| 16:11:35 | sean-k-mooney | well tenant network are intended to be aviable across all AZ and cells so unless you using l3 routed networks that the default | |
| 16:11:36 | noonedeadpunk | I just bet there are plenty scheduling complications on top.... | |
| 16:11:53 | sean-k-mooney | also there is no cell concep on the neutron side so its 1 neutron for all cells by default | |
| 16:11:53 | noonedeadpunk | right, which is not the case with keystone regions | |
| 16:18:46 | tkajinam | stephenfin, do you mind voting +A when you have time ? https://review.opendev.org/c/openstack/nova/+/943083 +A was postponed due to feature freeze period of 2025.2 but the freeze was lifted, apparently | |
| 16:19:04 | tkajinam | sean-k-mooney, or if you have time | |
| 16:23:32 | opendevreview | Takashi Kajinami proposed openstack/nova master: Replace remaining reference to policy.json https://review.opendev.org/c/openstack/nova/+/970648 | |
| 16:38:20 | noonedeadpunk | I also assume that for multi-cell environment, you pretty much never want to use template urls, as I'd guess it will make super conductor extremely confused? | |
| 16:39:10 | noonedeadpunk | or force to use the same password for all cells? | |
| 16:43:04 | sean-k-mooney | yes either works. | |
| 16:44:14 | sean-k-mooney | template urls were built for tripleo ot remvoe password form the db but we intentionally do not use them in our new installer and revert to non templeted urls to simplicy mangement of them over time | |
| 16:44:31 | sean-k-mooney | they are useful in theory but less so in practice | |
| 16:46:30 | noonedeadpunk | we have adapted them quite some time ago as well, because of some bug in nova-manage - when a command with different password was just creating another cell. So it was breaking nova on password rotation process | |
| 16:46:41 | noonedeadpunk | (I bet I reported it) | |
| 16:47:34 | noonedeadpunk | as then you also need to properly time update of the cell with service restart.... | |
| 16:49:00 | noonedeadpunk | https://bugs.launchpad.net/nova/+bug/1923899 | |
| 16:49:17 | noonedeadpunk | it's still in review :D | |
| 16:49:44 | sean-k-mooney | you should not return the create cell command | |
| 16:49:55 | sean-k-mooney | that is not for updating the cell | |
| 16:50:03 | sean-k-mooney | it sfor creating a new one | |
| 16:50:37 | sean-k-mooney | if you want ot update use the update command https://docs.openstack.org/nova/latest/cli/nova-manage.html#cell-v2-update-cell | |
| 16:51:01 | sean-k-mooney | the name is for human uses only its not the uniuqe identifyer | |
| 16:52:10 | sean-k-mooney | this is somewhere between user error and a missign unique constratit | |
| 16:52:33 | sean-k-mooney | interally nova only uses the cell uuid for joins | |
| 16:52:59 | noonedeadpunk | I Guess it's kidna general expectation of name_or_uuid behavior as well... | |
| 16:53:16 | sean-k-mooney | right that not the documented behavior | |
| 16:53:24 | sean-k-mooney | and we dont support that for nova-mange normally | |
| 16:53:29 | noonedeadpunk | as it's kinda hard in automated tooling to reference by uuid, but yeah, I get the point | |
| 16:53:30 | sean-k-mooney | that a openstack client thing | |
| 16:53:48 | sean-k-mooney | not somethng that the api or project -manage command typeicly support | |
| 16:54:44 | sean-k-mooney | the propsed path is not actully a fix | |
| 16:54:58 | sean-k-mooney | its a nova status commadn to detech cells with the same name | |
| 16:55:19 | sean-k-mooney | it does tno prevnet it from happeign or actully adress te bug | |
| 16:55:40 | sean-k-mooney | well there are two https://review.opendev.org/c/openstack/nova/+/901810 | |
| 16:55:49 | sean-k-mooney | is the nova-status check | |
| 16:56:39 | noonedeadpunk | it could be helpful as well, but yeah... | |
| 16:56:40 | sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/876940 changed the unique constrating but that has upgrade impacts | |
| 16:59:16 | noonedeadpunk | how the heck notifications are even supposed to work in multi-cell envs.... | |
| 16:59:52 | noonedeadpunk | or well. you set yet another rabbitmq cluster for notifications ,and all services can report to it.... | |
| 16:59:57 | noonedeadpunk | I guess that's the way.... | |
| 17:00:08 | sean-k-mooney | well you are recommened to use a dedicated rabbit for notrication regardless of cells | |
| 17:00:52 | sean-k-mooney | so it does not really change that you eithe ruse one rabbit for noticaion for all cells or you need to have 1 per cell and listnet to muptle notificions busses in yoru applcations | |
| 17:01:00 | noonedeadpunk | and then they are not scaled with cells, simple as that I guerss | |
| 17:01:22 | noonedeadpunk | oh, right... or that | |
| 17:01:26 | sean-k-mooney | it depend i belive celipmenter supprots a list of notificaon transport urls | |
| 17:01:48 | sean-k-mooney | but its more commont to just use 1 dedicated rabbit for them | |
| 17:02:46 | sean-k-mooney | but again that not really difent then a normal deployment where the recommadnation has alwasy beend seperate rpc and notficaiton traffic to diffent rabbit instances | |