← Back to team overview

openstack team mailing list archive

Re: Pondering multi-tenant needs in nova.


Hey Paul, yeah, see what happens when you take a little time away from email? ;P

So, I'm satisfied that I've highlighted the trade-offs that come along
with Nova not "inherently understanding the relationships between

Having an external system understand these account relationships is
fine, and the posters on this thread have done a good job explaining
the benefits that come along with federating the responsibility to an
external plugin/service, but there are some performance issues that
come along with it. However, as long as these inefficiencies are
known, I'm satisfied. :)


On Mon, Feb 7, 2011 at 11:37 PM, Paul Voccio <paul.voccio@xxxxxxxxxxxxx> wrote:
> 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
>>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. :)
>>> # 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.

Follow ups