Open Stack

Hi,

I believe they are neutron revisions, here's the output from  
yesterday's neutron-db-manage attempt:

---snip---
Nov 23 12:51:51 controller01 neutron-db-manage[25913]: INFO   
[alembic.runtime.migration] Context impl MySQLImpl.
Nov 23 12:51:51 controller01 neutron-db-manage[25913]: INFO   
[alembic.runtime.migration] Will assume non-transactional DDL.
Nov 23 12:51:51 controller01 neutron-db-manage[25913]: INFO   
[alembic.runtime.migration] Context impl MySQLImpl.
Nov 23 12:51:51 controller01 neutron-db-manage[25913]: INFO   
[alembic.runtime.migration] Will assume non-transactional DDL.
Nov 23 12:51:51 controller01 neutron-db-manage[25913]: INFO   
[alembic.runtime.migration] Running upgrade 5c85685d616d -> c43a0ddb6a03
Nov 23 12:51:51 controller01 neutron-db-manage[25913]: INFO   
[alembic.runtime.migration] Running upgrade c43a0ddb6a03 -> b5344a66e818
Nov 23 12:51:51 controller01 neutron-db-manage[25913]: INFO   
[alembic.runtime.migration] Running upgrade b5344a66e818 -> bebe95aae4d4
Nov 23 12:51:51 controller01 neutron-db-manage[25913]: INFO   
[alembic.runtime.migration] Running upgrade c613d0b82681 -> 6c9eb0469914
Nov 23 12:51:51 controller01 neutron-db-manage[25913]: INFO   
[alembic.runtime.migration] Running upgrade 6c9eb0469914 -> 633d74ebbc4b
Nov 23 12:51:52 controller01 neutron-db-manage[25913]: Running upgrade  
for neutron ...
Nov 23 12:51:52 controller01 neutron-db-manage[25913]: OK
---snip---

And here's where they are located, apparently from train version:

---snip---
controller01:~ # grep -r 633d74ebbc4b /usr/lib/python3.6/site-packages/
Übereinstimmungen in Binärdatei  
/usr/lib/python3.6/site-packages/neutron/db/migration/alembic_migrations/versions/train/expand/__pycache__/633d74ebbc4b_.cpython-36.pyc
/usr/lib/python3.6/site-packages/neutron/db/migration/alembic_migrations/versions/train/expand/633d74ebbc4b_.py:Revision ID:  
633d74ebbc4b
/usr/lib/python3.6/site-packages/neutron/db/migration/alembic_migrations/versions/train/expand/633d74ebbc4b_.py:revision =  
'633d74ebbc4b'
---snip---

Next week we'll try it with merging fresh victoria schema with our  
production data, then run the upgrade command again.

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

> Hi Eugen:
>
> I don't know how it is possible that you have 3 registers in this table.
> And the first two are not IDs of any Neutron revision. I would suggest you
> to (1) check the DB schema deployed against a fresh deployed system (in
> Victoria version) and (2) fix this table to point to the correct revision
> numbers.
>
> Regards.
>
>
> On Fri, Nov 25, 2022 at 3:51 PM Eugen Block <eblock at nde.ag> wrote:
>
>> 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---
>> >>
>> >>
>> >>
>>
>>
>>
>>