Open Stack

The main issue is when the relevant tables are moved into a separate service a la quantum or cinder.  We can't keep referential integrity across multiple databases, so the foreign keys in this case need to be removed. It leads to an odd situation when there is still an internal implementation in addition to the external implementation because the internal implementation no longer has foreign keys.

As an example, we used to have foreign key relationships between instances and networks.  We can no longer have these because we support networks declared externally.  The internal network management now has no referential integrity, but this is the price we pay for separation of concerns.  We are going through a similar set of relationship-breaking with the volume code.

Vish

On Apr 25, 2012, at 11:02 AM, Doug Hellmann wrote:

> 
> 
> On Wed, Apr 25, 2012 at 7:38 AM, Andrew Hutchings <andrew at linuxjedi.co.uk> wrote:
> On 12/04/12 13:35, J. Daniel Schmidt wrote:
> > While testing our SUSE OpenStack packages we hit a nasty bug and reported it
> > as:  https://bugs.launchpad.net/keystone/+bug/972502
> >
> > We found out that the underlying cause was a lack of referential integrity[1]
> > using sqlite or mysql. When we tried to reproduce this issue on postgresql the
> > usage of foreign keys greatly helped to find the cause.
> 
> >From a MySQL prospective that is probably more of an argument to use
> transactions, not foreign keys.
> 
> Transactions and referential integrity are related, but not equivalent. Without referential integrity it's quite easy to commit a transaction that leaves the database in a logically inconsistent state (it sounds like that's what was happening in the case described by the OP).
> 
> Is there a technical reason to disable strict referential integrity checking with MySQL?
> 
> Doug
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120425/995fe2df/attachment.html>