[openstack-dev] [neutron] Upgrading from Kilo to Liberty, missing database entries
Ihar Hrachyshka
ihrachys at redhat.com
Thu Mar 17 16:17:22 UTC 2016
Nolan Brubaker <nolan.brubaker at RACKSPACE.COM> wrote:
> Hello,
>
> Recently when testing neutron upgrades for openstack-ansible, I ran into
> an existing bug [1] where the networksecuritybindings and
> portsecuritybindings tables were not populated after an upgrade from Kilo
> to Liberty. Updating the table manually resolved the issue, as mentioned
> in the bug, but there’s been no further activity since that discovery.
>
> Also mentioned in the bug is a migration [2] that should fix this. From
> my investigation, it appears this migration runs on Kilo install, where
> the networksecuritybindings and portsecuritybindings tables don’t exist.
> Then, when upgrading to Liberty, it is skipped by Alembic as it’s already
> run. Manually running neutron-db-manage again skips this migration
> because the database is already current.
>
> Based on the above, I have 2 main questions:
>
>
> 1) Is this a known issue, or is there possibly a step I’m missing?
Yeah. To trigger the bug, you don’t need to upgrade. Just create a
network/port without the extension enabled; then enable the extension; then
try to start an instance using the network/port.
> 2) Is my understanding of the migrations correct, that the migration only
> runs in Kilo then is skipped in Liberty?
I don’t believe the alembic migration was the right way to go. Instead,
port security db code should be resilient against bindings not being
present in db (for resources created before extension was enabled). If
binding is not in db, we should assume True for the boolean value; and if
it’s not present in db when update is requested, then we should create a
new binding.
I posted a patch that should solve it: https://review.openstack.org/294132
I believe the patch should be backported back to the first release that
introduced the extension (Kilo). Also, with the patch, alembic script is
redundant and only adds to downtime during upgrade, so we could probably
kill it in stable branches in addition to this patch.
Ihar
More information about the OpenStack-dev
mailing list