Open Stack

On 12/16/2013 11:01 AM, Shawn Hartsock wrote:
> +1 on a migration to make uuid a non-nullable column. I advocated a few
> patches back in Havana that make assumptions based on the UUID being
> present and unique per instance. If it gets nulled the VMware drivers
> will have have breakage and I have no idea how to avoid that reasonably
> without the UUID.
>
>
> On Mon, Dec 16, 2013 at 11:59 AM, Russell Bryant <rbryant at redhat.com
> <mailto:rbryant at redhat.com>> wrote:
>
>     On 12/16/2013 11:45 AM, Matt Riedemann wrote:
>      > 1. Add a migration to change instances.uuid to non-nullable.
>     Besides the
>      > obvious con of having yet another migration script, this seems
>     the most
>      > straight-forward. The instance object class already defines the uuid
>      > field as non-nullable, so it's constrained at the objects layer, just
>      > not in the DB model.  Plus I don't think we'd ever have a case where
>      > instance.uuid is null, right?  Seems like a lot of things would break
>      > down if that happened.  With this option I can build on top of it for
>      > the DB2 migration support to add the same FKs as the other engines.
>
>     Yeah, having instance.uuid nullable doesn't seem valuable to me, so this
>     seems OK.
>
>     --
>     Russell Bryant
>
>     _______________________________________________
>     OpenStack-dev mailing list
>     OpenStack-dev at lists.openstack.org
>     <mailto:OpenStack-dev at lists.openstack.org>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> --
> # Shawn.Hartsock - twitter: @hartsock - plus.google.com/+ShawnHartsock
> <http://plus.google.com/+ShawnHartsock>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

I've been working on this more and am running up against some issues, 
part of this has to do with my lack of sqlalchemy know-how and 
inexperience with writing DB migrations, so dumping some info/problems 
here to see where people would like me to take this.

My original thinking for doing a migration was to delete the instances 
records where uuid == None and then move those to shadow_instances, then 
make instances.uuid.nullable=False.  Some of the problems with this 
approach are:

1. There are at least 5 other tables related to instances that need to 
be handled for a delete: InstanceFault, InstanceMetadata, 
InstanceSystemMetadata, InstanceInfoCache and 
SecurityGroupInstanceAssociation. Also, these tables don't define their 
instance_uuid column the same way, some have it nullable=False and 
others don't.

2. I'm not sure if I can use a session in the migration to make it a 
transaction.

3. This would make the instances and shadow_instances tables have 
different schemas, i.e. instances.uuid would be nullable=False in 
instances but nullable=True in shadow_instances.  Maybe this doesn't matter.

The whole reason behind using shadow_instances (or any backup table I 
guess) was so I could restore the records on DB downgrade.

So the more I think about this, I'm getting to the point of asking:

1. Do we even care about instances where uuid is None?  I'd have to 
think those wouldn't be working well in the current code with how 
everything relies on uuid for foreign keys and tracking relationships to 
volumes, images and networks across services.  If the answer is 'no' 
then the migration is pretty simple, just delete the records where uuid 
is None and be done with it.  You couldn't downgrade to get them back, 
but in this case we're asserting that we don't want them back.

2. Have an alternative schema in the DB2 case. This would be handled in 
the 216_havana migration when the instances table is defined and 
created, we'd just make the uuid column non-nullable in the DB2 case and 
leave it nullable for all other engines.  Anyone moving to DB2 would 
have to install from scratch anyway since there is no tooling to migrate 
a MySQL DB to DB2, for example.  As it stands, the 216_havana migration 
in my patch [1] already has a different schema for DB2 because of the 
foreign keys it can't create due to this problem.

Anyway, looking for some thoughts on how to best handle this, or if 
anyone has other ideas or good reasons why either approach couldn't be used.

[1] https://review.openstack.org/#/c/69047/

-- 

Thanks,

Matt Riedemann