openstack team mailing list archive

["Vaze, Mandar" <Mandar.Vaze@xxxxxxxxxxx>]

+1 for data integrity  ...

Here is an example that could use data integrity check :

tenant information is managed in keystone DB
ovs_quantum DB has tenant_id column for networks table.
When I use stack.sh - it puts a string "default" in tenant_id column - when it creates network via "nova-manage network create" and it WORKS !!!! 

I see two problems here :

1. tenant_id are uuid - so string "default" should be rejected with check _is_like_uuid - but that is only partial solution.
2. tenant_id should be valid ID from keystone.tenants


-Mandar


-----Original Message-----
From: openstack-bounces+mandar.vaze=nttdata.com@xxxxxxxxxxxxxxxxxxx [mailto:openstack-bounces+mandar.vaze=nttdata.com@xxxxxxxxxxxxxxxxxxx] On Behalf Of Philipp Wollermann
Sent: Friday, April 20, 2012 7:36 AM
To: J. Daniel Schmidt
Cc: openstack
Subject: Re: [Openstack] Using Foreign Keys

Hi,

On Apr 12, 2012, at 21:35, J. Daniel Schmidt wrote:

> One reviewer commented:
>> i don't approve of adding foreign keys, and we should probably remove 
>> the existing ones (in UserTenantMembership and in Endpoint)
> 
> and on
>> we shouldn't be using foreign keys at all, they are a crutch that are 
>> not available everywhere
> 

what the ... !?

I'm not actively participating in OpenStack development yet, so my opinion may carry no weight - but this is ridiculous. IMHO OpenStack is not some "who needs data integrity anyway"-web2.0 project, it's meant to provide a stable, robust platform where people run mission-critical production stuff. Calling our test cluster in the office "BrokenStack" is fun for a while and the "0 days since last exception" sign wasn't bad either, but the fun stops when you actually need to depend on this software running. We should implement as many checks for integrity and validity of data as possible and if a foreign key actually catches something, that means that your last line of defense just stopped the worst and you should have failed much earlier. And someone is actually thinking about *removing* that?

I'm all for a switch to the "add as much foreign keys as we can" policy. Actually, why are they not created automatically? If one uses an ORM correctly, there should be no way to actually *not* create them.

--
Philipp Wollermann

Infrastructure Engineer
CyberAgent, Inc. (Tokyo)
https://github.com/philwo



_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to     : openstack@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

______________________________________________________________________
Disclaimer:This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data.  If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding