openstack team mailing list archive

[Paul Voccio <paul.voccio@xxxxxxxxxxxxx>]

On 2/8/11 10:30 AM, "Vishvananda Ishaya" <vishvananda@xxxxxxxxx> wrote:

>This thread is enormous, so I'm I'm going to briefly summarize the two
>options as I see them:
>
>1.  Project Id is an opaque string, and it simply represents some kind of
>collection of users.  It is the
>responsibility of external systems (authn, authz, billing, and
>monitoring) to define what the string
>means, and what the relationships between the different "groups" and
>objects are.  Nova needs a
>few plug-in points to authn and authz, but the logic relating these
>projects to users happens external
>to the nova code.  Networking concerns are isolated to the project level.
>Pros:
> * Almost no changes to existing code (supporting multiple networks per
>project isonly necessary if
>    we want to support multi-tenancy in vlan mode)

Won't we still have to support multiple networks per project in flat
networking as well? You could go into multiple zones, supported by
different networking gear that will need different networks routed to
them. 

> * project code is simple and unencumbered (most small deployments don't
>need multi-tenancy)
>Cons:
> * pushing a lot of potentially useful code into external systems
> * potential for lack of code sharing between external sytsems
>
>2.  We change the project code into a more general concept of groups.
>Groups can contain other
>groups, and users and groups can be members of multiple groups.  This
>would mirror the possibilities
>available in ldap.
>Pros:
> * Greater flexibility of implementation.
> * Group implementation code is in one place, minimizing different
>implementations per component
>Cons:
> * Much more complexity in the nova code.
> * The greater complexity/flexibility won't be needed for smaller
>deployments.

This seems like it is an issue only larger deployments of Nova will
encounter. Trying to guess how someone will try to implement and bill for
resellers and groups and which group should have access to another group's
resources seems almost out of scope at the moment.


>
>Both of these options seem viable to me, but I'm actually leaning toward
>adding flexible groups into
>nova proper.  A complete authentication system IMO needs to support,
>flexible groups.  If we increase
>the flexibility of nova in this regard, it gives us a springboard to
>breaking out authz into a more complete
>separate service.  I like this more than rewriting the entire thing from
>scratch as a completely new component.
>
>Vish
>
>
>
>On Feb 8, 2011, at 8:11 AM, Jay Pipes wrote:
>
>> 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
>> accounts".
>> 
>> 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. :)
>> 
>> Cheers!
>> jay
>> 
>> 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
>>>>> 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.
>>> 
>>> 
>> 
>> _______________________________________________
>> 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.