Vish, Thanks for the detailed explanation. I didn't mean to imply that fixing it is trivial. ( I did realize that since keystone could be using different DB server, it might not be trivial for nova-manage to "validate" the tenant_id)
I was just supporting the argument in favor of data integrity :) -Mandar -----Original Message----- From: Vishvananda Ishaya [mailto:vishvana...@gmail.com] Sent: Friday, April 20, 2012 11:47 AM To: Vaze, Mandar Cc: Philipp Wollermann; J. Daniel Schmidt; openstack Subject: Re: [Openstack] Using Foreign Keys On Apr 19, 2012, at 8:59 PM, Vaze, Mandar wrote: > +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. tenant_ids are strings. It is an implementation detail that keystone uses uuids. > 2. tenant_id should be valid ID from keystone.tenants This would require nova-manage having logic to be able to connect to keystone which it doesn't have. One of the drawbacks of having decoupled services is everything isn't in one database where you can support foreign keys. We could in theory add logic to nova to allow it to verify things inside of keystone, but I'm not sure this makes sense from a security perspective. It would require nova to have administrative access to keystone to find out what tenants exist. Alternatively we could force administrative commands like network create to be done through the api using the context of the intended network. This has a drawback as well of making things administratively more difficult. An admin would have to get an administrative token for the intended tenant somehow before making the call. Vish ______________________________________________________________________ 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 _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
