openstack team mailing list archive

[Aimon Bustardo <abustardo@xxxxxxxx>]

Hi all, I am a bit concerned over what I am inferring about networking
modes in OpenStack from this thread. Is it proposed that we will support
only one mode per install/tenant/account/project/whatever? If so I
believe this to be a very limited view of how this can/should work. Or
is my inference wrong?




Aimon

On 2/8/11 10:41 AM, Vishvananda Ishaya wrote:
> 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.
>>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> 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@xxxxxx