openstack team mailing list archive

[Paul Voccio <paul.voccio@xxxxxxxxxxxxx>]

Woah, seems I missed a lot by not being around email today.

I was a bit confused at to why we would want to have nova trackif an
account was being used by a reseller. In digging back through the
blueprint associated with this, it seems the idea is for the operator (in
this case Rackspace, but whoever) of Nova should track the idea of a
reseller and accounts associated with that reseller. Nova itself would
still retain the idea of a single account and the resources associated
with that account. I guess this doesn't feel any different than another
managed service provider who is doing add-on business on top of a amazon,
rackspace, linode or other cloud business.

https://blueprints.launchpad.net/nova/+spec/multi-tenant-accounting,
specifically:

http://wiki.openstack.org/openstack-accounting?action=AttachFile&do=view&ta
rget=accounts.pdf

While an operator *could* implement the account id as an arbitrary string
and map inefficient queries to it as Jay mentions, I'm not sure they would
(or even should). 

Jay -- I think I understand your concerns, but are you suggesting we
implement the idea layer of resellers into Nova? Did I miss the point?
Sorry if I'm late to the party on this one.

Pvo


On 2/7/11 8:20 PM, "Eric Day" <eday@xxxxxxxxxxxx> wrote:

>On Mon, Feb 07, 2011 at 08:50:58PM -0500, Jay Pipes wrote:
>> Eric, you and I have a database background. I know you understand that
>>this:
>
>Of course, but the first pair of queries is not as bad as a query
>for every entity ID returned, which was in one of the previous emails
>(the main thing I was trying to address).
>
>There are other indexing tricks we can do as well, but lets not bother
>pre-optimizing in email pseudo code. :)
>
>-Eric
>
>> # Executed in the "auth service" or "configuration management
>> database" as Jorge calls it:
>> SELECT entity_id FROM entities
>> WHERE user_id = <request.user_id>
>> 
>> # Executed in the Nova database:
>> SELECT * FROM instances
>> JOIN instance_entity_map ON instance.id=instance_entity_map.instance_id
>> WHERE instance_entity_map.entity_id in (<entity_ids>);
>> 
>> is not the same as this:
>> 
>> # Executed in the Nova database:
>> SELECT * FROM instances
>> JOIN instance_entity_map iem ON instance.id=iem.instance_id
>> JOIN entities ON entities.entity_id = iem.entity_id
>> JOIN users ON iem.user_id = <request.user_id> # This last join would,
>> in practice, be a BETWEEN predicate on a self-join to the entities
>> table
>> 
>> One query on a database versus two queries (one on each database).
>> 
>> Let's not talk about distributed join flattening as if it somehow is a
>> single query when in fact it isn't.
>> 
>> -jay
>
>_______________________________________________
>Mailing list: https://launchpad.net/~openstack
>Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>Unsubscribe : https://launchpad.net/~openstack
>More help   : https://help.launchpad.net/ListHelp



Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intended for the exclusive and confidential use of the
individual or entity to which this message is addressed, and unless otherwise
expressly indicated, is confidential and privileged information of Rackspace.
Any dissemination, distribution or copying of the enclosed material is prohibited.
If you receive this transmission in error, please notify us immediately by e-mail
at abuse@xxxxxxxxxxxxx, and delete the original message.
Your cooperation is appreciated.