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 <rbry...@redhat.com
<mailto:rbry...@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@lists.openstack.org
<mailto:OpenStack-dev@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@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
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
