Open Stack

Hi,

thanks for your quick response.

> In Neutron we don't support contract operations since Newton.
>
> If you are in Victoria and you correctly finished the DB migration, your
> HEADs should be:
> * contract: 5c85685d616d (from Newton)
> * expand: I38991de2b4 (from the last DB change in Victoria,
> source_and_destination_ip_prefix_neutron_metering_rule)

That explains why I saw the newton revision in a new victoria cluster :-)

> Please check what you have in the DB table neutron.alembic_version. The
> first register should be the expand number, the second the contract one. If
> not, update them with the ones I've provided.

The table alembic_versions contains the three versions I provided at  
the end of my email:

MariaDB [neutron]> select * from alembic_version;
+--------------+
| version_num  |
+--------------+
| 633d74ebbc4b |
| bebe95aae4d4 |
| I38991de2b4  |
+--------------+

I already tried to manipulate the table so I would only have those two  
versions you already mentioned, but then the upgrade --expand command  
alternates the database again with the mentioned error message  
("Multiple heads are present").

> Before executing the
> migration tool again, be sure the DB schema matches the latest migration
> patch for your version. You can deploy a VM with devstack and run this
> version.

That's what I wanted to try next, export only the db schema (no data)  
from a working victoria neutron database, then export only data from  
our production db and merge those, then import that into the  
production and try to run upgrade --expand and --contract again. But I  
didn't want to fiddle around too much in the production, that's why I  
wanted to ask for your guidance first.
But IIUC even if I changed the table alembic_versions again and import  
the merged db, wouldn't upgrade --expand somehow try to alternate the  
table again? I don't see where the train revision comes from exactly,  
could you clarify, please? It seems like I always get back to square  
one when running the --expand command.

Thanks!
Eugen

Zitat von Rodolfo Alonso Hernandez <ralonsoh at redhat.com>:

> Hi Eugen:
>
> In Neutron we don't support contract operations since Newton.
>
> If you are in Victoria and you correctly finished the DB migration, your
> HEADs should be:
> * contract: 5c85685d616d (from Newton)
> * expand: I38991de2b4 (from the last DB change in Victoria,
> source_and_destination_ip_prefix_neutron_metering_rule)
>
> Please check what you have in the DB table neutron.alembic_version. The
> first register should be the expand number, the second the contract one. If
> not, update them with the ones I've provided. Before executing the
> migration tool again, be sure the DB schema matches the latest migration
> patch for your version. You can deploy a VM with devstack and run this
> version.
>
> Regards.
>
>
> On Fri, Nov 25, 2022 at 1:58 PM Eugen Block <eblock at nde.ag> wrote:
>
>> Hi *,
>>
>> I'd like to ask you for advice on how to clean up my neutron db. At
>> some point (which I don't know exactly, probably train) my neutron
>> database got inconsistent, apparently one of the upgrades did not go
>> as planned. The interesting thing is that the database still works, I
>> just upgraded from ussuri to victoria where that issue popped up again
>> during 'neutron-db-manage upgrade --expand', I'll add the information
>> at the end of this email. Apparently, I have multiple heads, and one
>> of them is from train, it seems as if I never ran --contract (or it
>> failed and I didn't notice).
>> Just some additional information what I did with this database: this
>> cloud started out as a test environment with a single control node and
>> then became a production environment. About two and a half years ago
>> we decided to reinstall this cloud with version ussuri and import the
>> databases. I had a virtual machine in which I upgraded the database
>> dump from production to the latest versions at that time. That all
>> worked quite well, I only didn't notice that something was missing.
>> Now that I finished the U --> V upgrade I want to fix this
>> inconsistency, I just have no idea how to do it. As I'm not sure how
>> all the neutron-db-manage commands work exactly I'd like to ask for
>> some guidance. For example, could the "stamp" command possibly help?
>> Or how else can I get rid of the train head and/or how to get the
>> train revision to "contract" so I can finish the upgrade and contract
>> the victoria revision? I can paste the whole neutron-db history if
>> necessary (neutron-db-manage history), please let me know what
>> information would be required to get to the bottom of this.
>> Any help is greatly appreciated!
>>
>> Thanks!
>> Eugen
>>
>>
>> ---snip---
>> controller01:~ # neutron-db-manage upgrade --expand
>> [...]
>> alembic.script.revision.MultipleHeads: Multiple heads are present for
>> given argument 'expand at head'; 633d74ebbc4b, I38991de2b4
>>
>> controller01:~ # neutron-db-manage current --verbose
>>    Running current for neutron ...
>> INFO  [alembic.runtime.migration] Context impl MySQLImpl.
>> INFO  [alembic.runtime.migration] Will assume non-transactional DDL.
>> Current revision(s) for mysql+pymysql://neutron:XXXXX@controller.fqdn
>> /neutron:
>> Rev: bebe95aae4d4 (head)
>> Parent: b5344a66e818
>> Branch names: contract
>> Path:
>>
>> /usr/lib/python3.6/site-packages/neutron/db/migration/alembic_migrations/versions/ussuri/contract/bebe95aae4d4_.py
>>
>> Rev: 633d74ebbc4b (head)
>> Parent: 6c9eb0469914
>> Branch names: expand
>> Path:
>>
>> /usr/lib/python3.6/site-packages/neutron/db/migration/alembic_migrations/versions/train/expand/633d74ebbc4b_.py
>>
>> Rev: I38991de2b4 (head)
>> Parent: 49d8622c5221
>> Branch names: expand
>> Path:
>>
>> /usr/lib/python3.6/site-packages/neutron/db/migration/alembic_migrations/versions/victoria/expand/I38991de2b4_source_and_destination_ip_prefix_neutron_metering_rule.py
>>
>>    OK
>> ---snip---
>>
>>
>>