Grizzly Fate - Part 2
In the previous post I went through some issues we had with our OpenStack upgrade from Grizzly to Icehouse.
We had successfully run the OpenStack update scripts, and we were in the Icehouse version. We started testing, and everything worked fine... until security groups. Well, they did work, they just weren't there. There was only a default security group per tenant. Looking more closely, we saw that the old database had the security groups in the security_groups table in the nova database, and in Icehouse we had it the securitygroups table in the neutron database. Oh bleep.
First order of business. Can we populate the database with the old info? Apparently, for most parts, yes. Luckily we had all the info available, since we had imported the old database.
First insert the security groups (except the default ones).
use nova; insert into neutron.securitygroups select project_id, id, name, description from security_groups where deleted=0 and name!="default";
Then the rules from non-default groups
insert into neutron.sercuritygrouprules select security_groups.project_id,security_group_rules.id,parent_group_id,NULL,"ingress","IPv4",protocol,from_port,to_port,cidr from security_group_rules join security_groups on security_groups.id=security_group_rules.parent_group_id where security_groups.deleted=0 and security_groups.name!="default";
And from the default groups (since we take the group ID from the neutron database)
insert into neutron.securitygrouprules select security_groups.project_id,security_group_rules.id,neutron.securitygroups.id,NULL,"ingress","IPv4",protocol,from_port,to_port,cidr from security_group_rules join security_groups on security_groups.id=security_group_rules.parent_group_id join neutron.securitygroups on neutron.securitygroups.name=security_groups.name and neutron.securitygroups.tenant_id=security_groups.project_id where security_groups.deleted=0 and security_groups.name="default";
Simple oneliners, eh?
Well, it seems that the changes didn't quite fix the problem. Horizon complained, since the old security group and rule IDs were not UUIDs.
- dump the sercurity group IDs
- use bash magic to generate an UUID per ID
- the same magic generates update statements for the sercuritygroups and sercuritygrouprules tables
- dump the security group rule IDs, reapply magic
This hacked together fix for the issues worked, but wasn't a great solution because
- Instance - security group mappings were lost
- New security group rules contain default egress rules. Migrated ones don't
When the nova-computes came online after the upgrade, they gradually started dropping the old security groups. So the main impact of this was that the customers had to re-add the security groups to their virtual machines, and virtual machines without the default security group had to have egress rules added to one of their security groups.
Geek. Product Owner @CSCfi