[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.


More information about the OpenStack-dev mailing list