| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-12-10 | |||
| 18:11:38 | noonedeadpunk | and also - I'm not sure about this one - does nova allows a VM to be a member of multiple server groups? | |
| 18:56:05 | opendevreview | Merged openstack/nova stable/2024.2: [ironic] Ensure unprovision happens for new states https://review.opendev.org/c/openstack/nova/+/969833 | |
| #openstack-nova - 2025-12-11 | |||
| 06:42:50 | opendevreview | yangjianfeng proposed openstack/nova master: Fix missing allocations due to unsuccessful evacuations https://review.opendev.org/c/openstack/nova/+/970335 | |
| 07:21:07 | opendevreview | huanhongda proposed openstack/nova master: live migration: Complete cleanup if post_live_migration fails https://review.opendev.org/c/openstack/nova/+/967652 | |
| 10:32:25 | opendevreview | yangjianfeng proposed openstack/nova master: [WIP] Fix: resources leak due to failed live-migration https://review.opendev.org/c/openstack/nova/+/970597 | |
| 13:11:20 | noonedeadpunk | hey folks! I've started looking into multi-cell docs (https://docs.openstack.org/nova/latest/admin/cells.html) and got kind of confused by sepr conductor part. Or specifically - how to tell it that it's a superconductor? | |
| 13:11:44 | noonedeadpunk | As, I can imagine, conductor is able to fetch cells connection details from the api database | |
| 13:11:56 | noonedeadpunk | but then how to tell a cell conductor not to do that? | |
| 13:12:43 | noonedeadpunk | and that it should operate only with own database, and never reach api database? Just don't define api_database section? | |
| 13:13:01 | noonedeadpunk | And also - does it make sense to do superconductor setup at all? | |
| 13:13:30 | noonedeadpunk | As in RHOSP 16 docs I've seen that still it has limit of 500 hosts across all cells... | |
| 13:13:45 | noonedeadpunk | (which I'd guess is due to network limit, but not sure) | |
| 13:48:51 | noonedeadpunk | so my guess is that super conductor just has an [api_database] section, while regular conductors only [database] | |
| 14:59:03 | opendevreview | Julien LE JEUNE proposed openstack/nova stable/2024.2: Fix bug 2000069 https://review.opendev.org/c/openstack/nova/+/970634 | |
| 15:26:09 | dansmith | noonedeadpunk: if you have multiple cells, you need a superconductor, or at least delegate one cell's conductors to be the superconductor function | |
| 15:28:09 | sean-k-mooney | noonedeadpunk: dont read teh RHOSP docs for anythign related to cells, if you do it will cuase you pain and confustion | |
| 15:28:26 | sean-k-mooney | noonedeadpunk: tripelo did not impelent cells well | |
| 15:28:54 | sean-k-mooney | the 500 limit in 16 was just that was what it was tested too | |
| 15:29:04 | sean-k-mooney | there is no actullly limit at 500 computes in nova | |
| 15:29:17 | sean-k-mooney | tripleo however had scaling issuees with 500+ servers | |
| 15:29:42 | dansmith | also that ^ :) | |
| 15:30:02 | sean-k-mooney | that was related to how it used heat and the heat -> ansible -> puppet workflow tripleo used | |
| 15:32:36 | noonedeadpunk | dansmith: but how you actually do that? | |
| 15:32:45 | noonedeadpunk | as I have not found option or any config reference | |
| 15:32:49 | dansmith | noonedeadpunk: do what? | |
| 15:33:02 | noonedeadpunk | do say that this conductor is a superconductor | |
| 15:33:15 | dansmith | noonedeadpunk: having an api_database is critical, but the superconductor is the conductor that your API nodes talk to over MQ, | |
| 15:33:37 | dansmith | so the [transport] of the API,scheduler, etc defines which conductors operate as the superconductor | |
| 15:33:42 | sean-k-mooney | each conductor uses a sepeate rabbtit clsuter or at least the rabbit vhost. the supper conductor is pointing at the cell0 rabbit cluster and has api access | |
| 15:34:08 | noonedeadpunk | I guess I'm kind of missing property to do so | |
| 15:34:39 | noonedeadpunk | I'd be assuming that superconductor get's connection details from the api_database? | |
| 15:34:43 | sean-k-mooney | the api db access enabeld the super conductor to conenct to the other rabbit message buess dbs for the other cells if needed to cordiate cross cell migration ectra | |
| 15:34:58 | sean-k-mooney | yep the cell mappign table | |
| 15:35:12 | noonedeadpunk | but like - what if you add api_database connection to all cell conductors? | |
| 15:35:34 | noonedeadpunk | but then they will also be configured to use own cell db/mq | |
| 15:35:38 | sean-k-mooney | that wont break anything | |
| 15:35:56 | sean-k-mooney | the importnat thing is that each cell has its own rabbit or rabbit vhost | |
| 15:35:57 | noonedeadpunk | so kinda this way all cell conductors are "superconductor"? | |
| 15:36:19 | sean-k-mooney | so the condutors and compute for a given cell use a specific rabbit | |
| 15:36:28 | dansmith | I guess sean-k-mooney wants to answer this, so I guess I'll back off | |
| 15:36:46 | sean-k-mooney | no go ahaed if you like | |
| 15:37:16 | noonedeadpunk | eventually osa also lacks proper multicell, despite some our users have it | |
| 15:37:20 | sean-k-mooney | i just wated to give a higelevel over view i tough i had a good link but i am not finding it in my history | |
| 15:37:46 | noonedeadpunk | so I wanted to implement it, but I fail to get to the bottom of how everything is connected, and I did not found any super relevant options in nova.conf reference | |
| 15:38:02 | noonedeadpunk | https://docs.openstack.org/nova/latest/admin/cells.html ? | |
| 15:38:09 | sean-k-mooney | noonedeadpunk: if you are not aware dansmith is nova cell expert. they did a good summit talk on how it works a few years ago | |
| 15:39:46 | sean-k-mooney | https://www.youtube.com/watch?v=o7jkqzORij8 is the link i was looking for | |
| 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 | |