Open Stack

inline:

On 2/8/11 8:30 AM, Vishvananda Ishaya 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)
>  * project code is simple and unencumbered (most small deployments don't need multi-tenancy)
This is not a Pro, this is a Con. We must design OpenStack around the
largest possible deployment while keeping the small ones in mind, not
the other way around.

Furthermore about multi-tenancy: a) Why are we thinking of multi-tenancy
as an optional component? It should be multi-tenancy by nature in that
any "tenant" can have a "sub-tenant". At some level don't we want a
supreme tenant that can control all others? In which case all it is is
tenants and sub-tenants.

Perhaps I am simply off base here in the relations between
tenants->Accounts->...->"Clouds(vms, network, storage services, etc.,
etc.)". Is this clearly defined now? If I am off base would someone be
so kind and educate this poor sole by pointing me to a link :)


Regards,

Aimon

 
> 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.
>
> 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 at rackspace.com> 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 at oddments.org> 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 at lists.launchpad.net
>>>> 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 at rackspace.com, and delete the original message.
>>> Your cooperation is appreciated.
>>>
>>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack at lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp

-- 
Aimon Bustardo | Morph Labs | +1.310.625.0608 (mobile) | +1.310.437.4898 (office) | www.morphlabs.com | aimon at mor.ph