Open Stack

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---
> >>
> >>
> >>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20221125/1ea02b2e/attachment-0001.htm>