"neutron-db-manage revision" complains about multiple heads

[vikram.choudhary]

openstack@nwbl-openstack:~/devstack$ neutron-db-manage revision -m "xxx"
  Running revision for neutron ...
  FAILED: Multiple heads are present; please specify the head revision on which the new revision should be
  based, or perform a merge.

[Armando Migliaccio (armando-migliaccio)]

what's xxx some migration with X-rated content?

[Armando Migliaccio (armando-migliaccio)]

:)

[vikram.choudhary (vikschw)]

Just for test ;)

[changzhi (changzhi)]

Does anyone fix it?

[Henry Gessau (gessau)]

Yes I am working on it.

[YAMAMOTO Takashi (yamamoto)]

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

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/223901
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=9d069c48aed3a087c5c51366c8e70b29f339e794
Submitter: Jenkins
Branch: master

commit 9d069c48aed3a087c5c51366c8e70b29f339e794
Author: Yuji <email address hidden>
Date: Wed Sep 16 11:45:27 2015 +0900

    Allow to specify branch for creating new migration

    Add options to 'neutron-db-manage revision' command for specifying
    a branch.

    DocImpact

    Change-Id: I00b00821839b0d77caaaf26b518c5c0c75e01218
    Closes-Bug: 1503342

[YujiAzama (azama-yuji)]

Henry, Thank you very much:)

[Miguel Angel Ajo (mangelajo)]

I agree, we should backport this if possible.

[Ann Taraday (akamyshnikova)]

Just curious: Why should we backport this? In stable/liberty we can not create new migrations, so what is the case when it is needed?

[Henry Gessau (gessau)]

Ann, the revision command without --autogenerate should work without giving this error. Also I believe out-of-tree extensions that have not yet released their liberty version may want to use the --autogenerate.

[Miguel Angel Ajo (mangelajo)]

And eventually, we could want to be able to backport migrations if necessary.

[Ann Taraday (akamyshnikova)]

@Henry: OK
@Miguel: backporting migrations is a very odd thing and will require checks in migrations, so that it won't crash with upgrade after that. This should be a very serious issue to do such staff.

[Miguel Angel Ajo (mangelajo)]

@ann, I know it's hard, but eventually it could get easier with better support from alembic, not sure if branches already allow such thing... We better not needed, I agree...

[Mike Bayer (zzzeek)]

@mangelajo - what is "such thing" in this context? you can merge branches in Alembic, I believe Ann is referring to the migration check feature they've added to Neutron.

[Dongcan Ye (hellochosen)]

@All

If I had an extension need to rebase to Liberty, when running command:

neutron-db-manage revision -m "****" --autogenerate

it will failed as error:
FAILED: Multiple heads are present; please specify the head revision on which the new revision should be based, or perform a merge.

But in Liberty, neutron-db-manage wrapper does't support --expand or --contract.

[Ihar Hrachyshka (ihar-hrachyshka)]

I believe a use case to create a new branch that will work with neutron/Liberty is a good one to consider backports. Please propose and let's follow up in gerrit.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/liberty
Review: https://review.openstack.org/247987

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/247987
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=d6a628e5453ed77af265c0a3c6cb2e1e6c0c22c9
Submitter: Jenkins
Branch: stable/liberty

commit d6a628e5453ed77af265c0a3c6cb2e1e6c0c22c9
Author: Yuji <email address hidden>
Date: Wed Sep 16 11:45:27 2015 +0900

    Allow to specify branch for creating new migration

    Add options to 'neutron-db-manage revision' command for specifying
    a branch.

    DocImpact

    Change-Id: I00b00821839b0d77caaaf26b518c5c0c75e01218
    Closes-Bug: 1503342
    (cherry picked from commit 9d069c48aed3a087c5c51366c8e70b29f339e794)

[Thierry Carrez (ttx)]

This issue was fixed in the openstack/neutron 8.0.0.0b1 development milestone.

[Doug Hellmann (doug-hellmann)]

This issue was fixed in the openstack/neutron 7.0.1 release.