[openstack-dev] [nova][db] Thoughts on making instances.uuid non-nullable?

Matt Riedemann mriedem at linux.vnet.ibm.com
Mon Mar 10 14:10:24 UTC 2014



On 3/9/2014 9:05 PM, ChangBo Guo wrote:
>
>
>
> 2014-03-10 4:47 GMT+08:00 Jay Pipes <jaypipes at gmail.com
> <mailto:jaypipes at gmail.com>>:
>
>
>
>      > 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.
>
>     No, I don't think this matters much, to be honest. I'm not entirely sure
>     what the long-term purpose of the shadow tables are in Nova -- perhaps
>     someone could clue me in to whether the plan is to keep them around?
>
> As I know the tables shadow_*  are used  by command ' nova-manage db
> archive_deleted_rows' , which moves  records with "deleted=True" to
> table shadow_* . That means these tables are used by other  process, So,
> I think we need other tables to store the old records in your migration .

So you mean move records where instances.uuid == None to 
shadow_instances?  That's not going to work though if we make the uuid 
column non-nullable on both instances and shadow_instances, unless you 
generate a random UUID for the shadow_instances table records that get 
moved, which is just another hack - and that would break moving them 
back on downgrade since you wouldn't know which records to move back, 
i.e. since you wouldn't be able to query shadow_instances for records 
where instances.uuid == None.

Other thoughts?  If you did really want to back these records up, I 
think it would have to be a different backup table rather than 
shadow_instances since I think we want to keep the schema the same 
between instances and shadow_instances.

>
>
>
>
> --
> ChangBo Guo(gcb)
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

-- 

Thanks,

Matt Riedemann




More information about the OpenStack-dev mailing list