On Mon, Feb 7, 2011 at 8:24 PM, Jorge Williams <jorge.willi...@rackspace.com> wrote: > On Feb 7, 2011, at 5:43 PM, Jay Pipes wrote: > >> What if I don't want to get "my" servers only? What if I want to list >> another organization's servers, and that organization's child >> organizations' servers? > > That sort of information and those sort of quires fall within the realm of > configuration management. So for any organization or customer or whatever > you should be able to ask: > > What resources belong to that customer/organization? (Note just compute > resources, but object store resources, or whatever) > What resources have been requested and are actively being provisioned? etc. > > There should be a service (the configuration management service) that's > there just for answering those sort of questions -- the service shouldn't > necessarily have to query nova or swift directly -- instead the underlying > configuration management database can be populated by listening to events > from swift and nova. > > The shape of the CMDB and what queries it's optimized to process will vary > from one deployment to another.
Yes, I understand what you, Eric, Monsyne, Greg, John, and others have been saying :) I am just saying that if the decision is to federate the responsibility of determining account relationships to an external service, that we should understand that the efficiency of certain queries is affected, and that API operations must, by nature, be restricted to a simpler set of operations -- i.e. "get me the list of servers attached to accounts X, Y, and Z", as opposed to "get me all servers attached to the X account and any of X's child accounts". The latter example, there must instead be split into two requests: one to the auth service for "get me all accounts, inclusively, of account X and all of X's child accounts", and another request to Nova for "get me all the servers attached to accounts X, Y, and Z", where X, Y, Z is the list of accounts returned by the first request. I'm not saying the federated auth/CMDB/whatever service is not a good idea nor that it will not work. I want people to understand and acknowledge the tradeoffs involved. Cheers, jay _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
