cells v2 accepts creating two cells with same name

[Corey Bryant]

I'm not seeing that nova-manage cell_v2 provides a way to update the transport_url (or database) for a cell. It's possible that I'm missing something here but I've not found a way to do this.

This is a problem when scaling rabbitmq, for example. If I have a cell associated with a single rabbitmq instance and I want to scale to 2 rmq instances, then there needs to be a way to update the database for the cell.

Running 'nova-manage cell_v2 create_cell --name cell1' twice, 1st time with the transport_url in nova.conf having one rmq server, and 2nd time with the transport_url in nova.conf having two rmq servers is successful. After this, there are two cell_mappings records for "cell1", and it appears that the first entry is what ends up being used for ensuing commands (ie. if I take the the original rmq out of active/active HA, I can't deploy an instance).

Here's what the cell_mappings table looks like after the 2nd create_cell call:

mysql> select * from cell_mappings;
+---------------------+------------+----+--------------------------------------+-------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------+
| created_at | updated_at | id | uuid | name | transport_url | database_connection |
+---------------------+------------+----+--------------------------------------+-------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------+
| 2017-02-14 21:06:49 | NULL | 1 | 00000000-0000-0000-0000-000000000000 | cell0 | none:/// | mysql://nova:7Jf4sgRNqbfzR8d3hxyWKYpzFfY6gK95@10.5.30.174/nova_cell0 |
| 2017-02-14 21:06:56 | NULL | 2 | 1499460c-41f2-422d-b452-03b7995907c4 | cell1 | rabbit://nova:PtPFqF24ZxsB5GqCRN77Pbrp4h3cCYgJJ9XJwBThPhF2kz9M2Trbg8CSpFVcjY5L@10.5.30.169:/openstack | mysql://nova:7Jf4sgRNqbfzR8d3hxyWKYpzFfY6gK95@10.5.30.174/nova |
| 2017-02-14 22:35:48 | NULL | 5 | 4b363076-7d89-451d-be99-057b0ad67e73 | cell1 | rabbit://nova:PtPFqF24ZxsB5GqCRN77Pbrp4h3cCYgJJ9XJwBThPhF2kz9M2Trbg8CSpFVcjY5L@10.5.30.169:,nova:PtPFqF24ZxsB5GqCRN77Pbrp4h3cCYgJJ9XJwBThPhF2kz9M2Trbg8CSpFVcjY5L@10.5.30.187:/openstack | mysql://nova:7Jf4sgRNqbfzR8d3hxyWKYpzFfY6gK95@10.5.30.174/nova |
+---------------------+------------+----+--------------------------------------+----

It seems as if the 2nd cell_create call should update the original cell1 record, or there should be an cell_update subcommand.

[Sylvain Bauza (sylvain-bauza)]

We should disallow the possibility to have a second row with the same cell name since it could clash later on.

That said, having the possibility to update the cell transport_url doesn't seem a bug to me, just a missing feature. For the moment, just update the DB directly.

[Corey Bryant (corey.bryant)]

I think that's quite a stretch to call this a feature and not a bug. Prior to cells v2 we didn't have to manually update any databases to scale rabbitmq and now we are forced to use cells v2 but we when we scale rabbitmq we now have to manually delete a record from the nova-api database in order to do so. That's pretty bad.

[Ryan Beisner (1chb1n)]

Agree, any time users/operators are channeled to do direct database operations, something has gone badly wrong.

[Dan Smith (danms)]

This is in ocata for rc2 already:

https://review.openstack.org/#/c/431582/

[Corey Bryant (corey.bryant)]

Dan, good to hear. Thanks for the update.

[Maciej Szankin (mszankin)]

Since the Mitaka cycle we use the direct release model, which means this bug report should be tagged Fix Released.