openstack team mailing list archive

[Vishvananda Ishaya <vishvananda@xxxxxxxxx>]

Projects aren't associated with networks in any other mode.  Networks are assigned by compute host.

Vish

On Feb 8, 2011, at 10:15 AM, Paul Voccio wrote:

> 
> 
> 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.
>