Re: [Openstack] Pondering multi-tenant needs in nova.

[Aimon Bustardo]

Hi Patrick,

that would be great if you would go into details. I am most interested
in this as it directly effects our cloud platforms adoption of OpenStack
and the subsequent networking blueprint we have designed (trying to get
a hold of the networking blueprint Ewan is leading also).


Thank you,


Aimon

On 2/3/11 10:18 PM, Patrick Ancillotti wrote:
> Aimon, 
>
> You're correct of course for simply defining a customer per VLAN as 
> realistically we wouldn't hit 16M+ customers in any regional area as it 
> stands today ;) but there are other issues with QinQ at large scale, 
> especially with Layer 2 domains of the size that we're envisaging in the long 
> run... many of which we can go into detail if you want?
>
> For those interested in QinQ : http://en.wikipedia.org/wiki/802.1QinQ
>
> Thanks, 
> Patrick 
>
> On 3 Feb 2011, at 23:45, Aimon Bustardo wrote:
>
>> Hi Patrick, by using 802.1QiQ aren't we increasing the total VLAN count
>> to 4096*4096 (16277216) possible VLANS, each with the possibility of
>> using the same /8 network? In which case he in table storage of MACs is
>> the limiting factor.
>>
>>
>> Aimon
>>
>> On 2/3/11 8:03 PM, Patrick Ancillotti wrote:
>>> Hey Guys, 
>>>
>>> I think Paul may have gotten a bit mixed up between VLAN and CAM tables on 
>>> switches. The VLAN part of an ethernet frame is 12 bits (0 - 4095) which 
>>> limits it accordingly. CAM tables however are a limit within switching gear 
>>> that lists the MAC addresses and their respective source and destination 
>>> ports. The lower end Cisco switches like the 2960 class switches have a 
>>> limit of around 8000 MAC addresses, whereas others higher in the stack such 
>>> as the 4948E class have limits upwards of 55000 MAC addresses, although 
>>> some vendors have CAM tables in the hundreds of thousands for even their 
>>> mid range switches. 
>>>
>>> That said, VLAN's are extremely limited, even with QinQ (VLANs within 
>>> VLANs) when you're talking about 50 000 customers, or even 500 000 
>>> customers in the same layer 2 domain, and in many cases using smaller layer 
>>> 2 domains creates unfortunately small service areas for capacity.
>>>
>>> For more info: 
>>> http://en.wikipedia.org/wiki/Virtual_LAN
>>> http://en.wikipedia.org/wiki/CAM_Table
>>>
>>> Thanks,
>>> Patrick
>>>
>>> On 3 Feb 2011, at 07:47, Paul Voccio wrote:
>>>
 Diego,

 Due to our networking topology, having a vlan per customer isn't really
 feasible. Most switches are limited at 4k or 8k or even 32k. With more
 customers than these switches can reasonably accommodate, having a single
 vlan per customer either limits the portability within a cloud or limits
 the scale at which you can build your cloud. Open vSwitch will alleviate
 some of this pain, but until we get it in XenServer, we're somewhat stuck
 on flat networking.

 Paul

 On 2/3/11 4:20 AM, "Diego Parrilla Santamaría"
  wrote:

> Hi Monsyne,
>
> it's a very interesting topic and I'm curious about the reason why you
> are using the Flat Networking set up. From the conversations in other
> threads it seems the Service Providers prefer different networking
> approaches: VLAN oriented basically.
>
> Regards
> Diego
>
> -
> Diego Parrilla
> nubeblog.com | nubeb...@nubeblog.com | twitter.com/nubeblog
> +34 649 94 43 29
>
>
>
>
> On Thu, Feb 3, 2011 at 2:37 AM, Monsyne Dragon 
> wrote:
>> I am sorting out some possible implementations for the
>> multi-tenant-accounting blueprint, and the related system-usage-records
>> bp,
>> and I just wanted to run this by anyone interested in such matters.
>>
>> Basically, for multitenant purposes we need to introduce the concept of
>> an
>> 'account' in nova, representing a customer,  that basically acts as a
>> label
>> for a group of resources (instances, etc), and for access control (i.e
>> customer a cannot mess w/ customer b's stuff)
>>
>> There was some confusion on how best to implement this, in relation to
>> nova's project concept.  Projects are kind of like what we want an
>> account
>> to be, but there are some associations (like one project per network)
>> which
>> are not valid for our flat networking setup.  I am kind of
>> straw-polling on
>> which is better here:
>>
>> The options are:
>> 1) Create a new 'account' concept in nova,  with an account basically
>> being
>> a subgroup of a project (providers would use a single, default project,
>> with
>> additional projects added if needed for separate brands, or resellers,
>> etc),
>> add in access control per account as well as project, and make sure
>> apis/auth specify account appropriately,  have some way for a default
>> account to used (per project) so account doesn't get in the way for
>> non-multitenant users.
>>
>> 

Re: [Openstack] Pondering multi-tenant needs in nova.

[Patrick Ancillotti]

Aimon, 

You're correct of course for simply defining a customer per VLAN as 
realistically we wouldn't hit 16M+ customers in any regional area as it stands 
today ;) but there are other issues with QinQ at large scale, especially with 
Layer 2 domains of the size that we're envisaging in the long run... many of 
which we can go into detail if you want?

For those interested in QinQ : http://en.wikipedia.org/wiki/802.1QinQ

Thanks, 
Patrick 

On 3 Feb 2011, at 23:45, Aimon Bustardo wrote:

> Hi Patrick, by using 802.1QiQ aren't we increasing the total VLAN count
> to 4096*4096 (16277216) possible VLANS, each with the possibility of
> using the same /8 network? In which case he in table storage of MACs is
> the limiting factor.
> 
> 
> Aimon
> 
> On 2/3/11 8:03 PM, Patrick Ancillotti wrote:
>> Hey Guys, 
>> 
>> I think Paul may have gotten a bit mixed up between VLAN and CAM tables on 
>> switches. The VLAN part of an ethernet frame is 12 bits (0 - 4095) which 
>> limits it accordingly. CAM tables however are a limit within switching gear 
>> that lists the MAC addresses and their respective source and destination 
>> ports. The lower end Cisco switches like the 2960 class switches have a 
>> limit of around 8000 MAC addresses, whereas others higher in the stack such 
>> as the 4948E class have limits upwards of 55000 MAC addresses, although some 
>> vendors have CAM tables in the hundreds of thousands for even their mid 
>> range switches. 
>> 
>> That said, VLAN's are extremely limited, even with QinQ (VLANs within VLANs) 
>> when you're talking about 50 000 customers, or even 500 000 customers in the 
>> same layer 2 domain, and in many cases using smaller layer 2 domains creates 
>> unfortunately small service areas for capacity.
>> 
>> For more info: 
>> http://en.wikipedia.org/wiki/Virtual_LAN
>> http://en.wikipedia.org/wiki/CAM_Table
>> 
>> Thanks,
>> Patrick
>> 
>> On 3 Feb 2011, at 07:47, Paul Voccio wrote:
>> 
>>> Diego,
>>> 
>>> Due to our networking topology, having a vlan per customer isn't really
>>> feasible. Most switches are limited at 4k or 8k or even 32k. With more
>>> customers than these switches can reasonably accommodate, having a single
>>> vlan per customer either limits the portability within a cloud or limits
>>> the scale at which you can build your cloud. Open vSwitch will alleviate
>>> some of this pain, but until we get it in XenServer, we're somewhat stuck
>>> on flat networking.
>>> 
>>> Paul
>>> 
>>> On 2/3/11 4:20 AM, "Diego Parrilla Santamaría"
>>>  wrote:
>>> 
 Hi Monsyne,
 
 it's a very interesting topic and I'm curious about the reason why you
 are using the Flat Networking set up. From the conversations in other
 threads it seems the Service Providers prefer different networking
 approaches: VLAN oriented basically.
 
 Regards
 Diego
 
 -
 Diego Parrilla
 nubeblog.com | nubeb...@nubeblog.com | twitter.com/nubeblog
 +34 649 94 43 29
 
 
 
 
 On Thu, Feb 3, 2011 at 2:37 AM, Monsyne Dragon 
 wrote:
> I am sorting out some possible implementations for the
> multi-tenant-accounting blueprint, and the related system-usage-records
> bp,
> and I just wanted to run this by anyone interested in such matters.
> 
> Basically, for multitenant purposes we need to introduce the concept of
> an
> 'account' in nova, representing a customer,  that basically acts as a
> label
> for a group of resources (instances, etc), and for access control (i.e
> customer a cannot mess w/ customer b's stuff)
> 
> There was some confusion on how best to implement this, in relation to
> nova's project concept.  Projects are kind of like what we want an
> account
> to be, but there are some associations (like one project per network)
> which
> are not valid for our flat networking setup.  I am kind of
> straw-polling on
> which is better here:
> 
> The options are:
> 1) Create a new 'account' concept in nova,  with an account basically
> being
> a subgroup of a project (providers would use a single, default project,
> with
> additional projects added if needed for separate brands, or resellers,
> etc),
> add in access control per account as well as project, and make sure
> apis/auth specify account appropriately,  have some way for a default
> account to used (per project) so account doesn't get in the way for
> non-multitenant users.
> 
> 2) having account == nova's "project", and changing the network
> associations, etc so projects can support our model (as well as current
> models).  Support for associating accounts (projects) together for
> resellers, etc would either be delegated outside of nova or added later
> (it's not a current requirement).
> 
> In either case, accounts would be identified by name, which would  be an
> opaque string an outside system/per

Re: [Openstack] Pondering multi-tenant needs in nova.

[Aimon Bustardo]

Hi Patrick, by using 802.1QiQ aren't we increasing the total VLAN count
to 4096*4096 (16277216) possible VLANS, each with the possibility of
using the same /8 network? In which case he in table storage of MACs is
the limiting factor.


Aimon

On 2/3/11 8:03 PM, Patrick Ancillotti wrote:
> Hey Guys, 
>
> I think Paul may have gotten a bit mixed up between VLAN and CAM tables on 
> switches. The VLAN part of an ethernet frame is 12 bits (0 - 4095) which 
> limits it accordingly. CAM tables however are a limit within switching gear 
> that lists the MAC addresses and their respective source and destination 
> ports. The lower end Cisco switches like the 2960 class switches have a limit 
> of around 8000 MAC addresses, whereas others higher in the stack such as the 
> 4948E class have limits upwards of 55000 MAC addresses, although some vendors 
> have CAM tables in the hundreds of thousands for even their mid range 
> switches. 
>
> That said, VLAN's are extremely limited, even with QinQ (VLANs within VLANs) 
> when you're talking about 50 000 customers, or even 500 000 customers in the 
> same layer 2 domain, and in many cases using smaller layer 2 domains creates 
> unfortunately small service areas for capacity.
>
> For more info: 
> http://en.wikipedia.org/wiki/Virtual_LAN
> http://en.wikipedia.org/wiki/CAM_Table
>
> Thanks,
> Patrick
>
> On 3 Feb 2011, at 07:47, Paul Voccio wrote:
>
>> Diego,
>>
>> Due to our networking topology, having a vlan per customer isn't really
>> feasible. Most switches are limited at 4k or 8k or even 32k. With more
>> customers than these switches can reasonably accommodate, having a single
>> vlan per customer either limits the portability within a cloud or limits
>> the scale at which you can build your cloud. Open vSwitch will alleviate
>> some of this pain, but until we get it in XenServer, we're somewhat stuck
>> on flat networking.
>>
>> Paul
>>
>> On 2/3/11 4:20 AM, "Diego Parrilla Santamaría"
>>  wrote:
>>
>>> Hi Monsyne,
>>>
>>> it's a very interesting topic and I'm curious about the reason why you
>>> are using the Flat Networking set up. From the conversations in other
>>> threads it seems the Service Providers prefer different networking
>>> approaches: VLAN oriented basically.
>>>
>>> Regards
>>> Diego
>>>
>>> -
>>> Diego Parrilla
>>> nubeblog.com | nubeb...@nubeblog.com | twitter.com/nubeblog
>>> +34 649 94 43 29
>>>
>>>
>>>
>>>
>>> On Thu, Feb 3, 2011 at 2:37 AM, Monsyne Dragon 
>>> wrote:
 I am sorting out some possible implementations for the
 multi-tenant-accounting blueprint, and the related system-usage-records
 bp,
 and I just wanted to run this by anyone interested in such matters.

 Basically, for multitenant purposes we need to introduce the concept of
 an
 'account' in nova, representing a customer,  that basically acts as a
 label
 for a group of resources (instances, etc), and for access control (i.e
 customer a cannot mess w/ customer b's stuff)

 There was some confusion on how best to implement this, in relation to
 nova's project concept.  Projects are kind of like what we want an
 account
 to be, but there are some associations (like one project per network)
 which
 are not valid for our flat networking setup.  I am kind of
 straw-polling on
 which is better here:

 The options are:
 1) Create a new 'account' concept in nova,  with an account basically
 being
 a subgroup of a project (providers would use a single, default project,
 with
 additional projects added if needed for separate brands, or resellers,
 etc),
 add in access control per account as well as project, and make sure
 apis/auth specify account appropriately,  have some way for a default
 account to used (per project) so account doesn't get in the way for
 non-multitenant users.

 2) having account == nova's "project", and changing the network
 associations, etc so projects can support our model (as well as current
 models).  Support for associating accounts (projects) together for
 resellers, etc would either be delegated outside of nova or added later
 (it's not a current requirement).

 In either case, accounts would be identified by name, which would  be an
 opaque string an outside system/person would assign, and could
 structure to
 their needs (ie. for associating accounts with common prefixes, etc)

 --

 --
   -Monsyne Dragon
   work: 210-312-4190
   mobile210-441-0965
   google voice: 210-338-0336



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

Re: [Openstack] Pondering multi-tenant needs in nova.

[Paul Voccio]

Patrick,

You're right.  I guess that¹s what I get for typing a response too fast.

Paul

On 2/3/11 10:03 PM, "Patrick Ancillotti"
 wrote:

>Hey Guys, 
>
>I think Paul may have gotten a bit mixed up between VLAN and CAM tables
>on switches. The VLAN part of an ethernet frame is 12 bits (0 - 4095)
>which limits it accordingly. CAM tables however are a limit within
>switching gear that lists the MAC addresses and their respective source
>and destination ports. The lower end Cisco switches like the 2960 class
>switches have a limit of around 8000 MAC addresses, whereas others higher
>in the stack such as the 4948E class have limits upwards of 55000 MAC
>addresses, although some vendors have CAM tables in the hundreds of
>thousands for even their mid range switches.
>
>That said, VLAN's are extremely limited, even with QinQ (VLANs within
>VLANs) when you're talking about 50 000 customers, or even 500 000
>customers in the same layer 2 domain, and in many cases using smaller
>layer 2 domains creates unfortunately small service areas for capacity.
>
>For more info: 
>http://en.wikipedia.org/wiki/Virtual_LAN
>http://en.wikipedia.org/wiki/CAM_Table
>
>Thanks,
>Patrick
>
>On 3 Feb 2011, at 07:47, Paul Voccio wrote:
>
>> Diego,
>> 
>> Due to our networking topology, having a vlan per customer isn't really
>> feasible. Most switches are limited at 4k or 8k or even 32k. With more
>> customers than these switches can reasonably accommodate, having a
>>single
>> vlan per customer either limits the portability within a cloud or limits
>> the scale at which you can build your cloud. Open vSwitch will alleviate
>> some of this pain, but until we get it in XenServer, we're somewhat
>>stuck
>> on flat networking.
>> 
>> Paul
>> 
>> On 2/3/11 4:20 AM, "Diego Parrilla Santamaría"
>>  wrote:
>> 
>>> Hi Monsyne,
>>> 
>>> it's a very interesting topic and I'm curious about the reason why you
>>> are using the Flat Networking set up. From the conversations in other
>>> threads it seems the Service Providers prefer different networking
>>> approaches: VLAN oriented basically.
>>> 
>>> Regards
>>> Diego
>>> 
>>> -
>>> Diego Parrilla
>>> nubeblog.com | nubeb...@nubeblog.com | twitter.com/nubeblog
>>> +34 649 94 43 29
>>> 
>>> 
>>> 
>>> 
>>> On Thu, Feb 3, 2011 at 2:37 AM, Monsyne Dragon 
>>> wrote:
 I am sorting out some possible implementations for the
 multi-tenant-accounting blueprint, and the related
system-usage-records
 bp,
 and I just wanted to run this by anyone interested in such matters.
 
 Basically, for multitenant purposes we need to introduce the concept
of
 an
 'account' in nova, representing a customer,  that basically acts as a
 label
 for a group of resources (instances, etc), and for access control (i.e
 customer a cannot mess w/ customer b's stuff)
 
 There was some confusion on how best to implement this, in relation to
 nova's project concept.  Projects are kind of like what we want an
 account
 to be, but there are some associations (like one project per network)
 which
 are not valid for our flat networking setup.  I am kind of
 straw-polling on
 which is better here:
 
 The options are:
 1) Create a new 'account' concept in nova,  with an account basically
 being
 a subgroup of a project (providers would use a single, default
project,
 with
 additional projects added if needed for separate brands, or resellers,
 etc),
 add in access control per account as well as project, and make sure
 apis/auth specify account appropriately,  have some way for a default
 account to used (per project) so account doesn't get in the way for
 non-multitenant users.
 
 2) having account == nova's "project", and changing the network
 associations, etc so projects can support our model (as well as
current
 models).  Support for associating accounts (projects) together for
 resellers, etc would either be delegated outside of nova or added
later
 (it's not a current requirement).
 
 In either case, accounts would be identified by name, which would  be
an
 opaque string an outside system/person would assign, and could
 structure to
 their needs (ie. for associating accounts with common prefixes, etc)
 
 --
 
 --
   -Monsyne Dragon
   work: 210-312-4190
   mobile210-441-0965
   google voice: 210-338-0336
 
 
 
 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 err

Re: [Openstack] Pondering multi-tenant needs in nova.

[Patrick Ancillotti]

Hey Guys, 

I think Paul may have gotten a bit mixed up between VLAN and CAM tables on 
switches. The VLAN part of an ethernet frame is 12 bits (0 - 4095) which limits 
it accordingly. CAM tables however are a limit within switching gear that lists 
the MAC addresses and their respective source and destination ports. The lower 
end Cisco switches like the 2960 class switches have a limit of around 8000 MAC 
addresses, whereas others higher in the stack such as the 4948E class have 
limits upwards of 55000 MAC addresses, although some vendors have CAM tables in 
the hundreds of thousands for even their mid range switches. 

That said, VLAN's are extremely limited, even with QinQ (VLANs within VLANs) 
when you're talking about 50 000 customers, or even 500 000 customers in the 
same layer 2 domain, and in many cases using smaller layer 2 domains creates 
unfortunately small service areas for capacity.

For more info: 
http://en.wikipedia.org/wiki/Virtual_LAN
http://en.wikipedia.org/wiki/CAM_Table

Thanks,
Patrick

On 3 Feb 2011, at 07:47, Paul Voccio wrote:

> Diego,
> 
> Due to our networking topology, having a vlan per customer isn't really
> feasible. Most switches are limited at 4k or 8k or even 32k. With more
> customers than these switches can reasonably accommodate, having a single
> vlan per customer either limits the portability within a cloud or limits
> the scale at which you can build your cloud. Open vSwitch will alleviate
> some of this pain, but until we get it in XenServer, we're somewhat stuck
> on flat networking.
> 
> Paul
> 
> On 2/3/11 4:20 AM, "Diego Parrilla Santamaría"
>  wrote:
> 
>> Hi Monsyne,
>> 
>> it's a very interesting topic and I'm curious about the reason why you
>> are using the Flat Networking set up. From the conversations in other
>> threads it seems the Service Providers prefer different networking
>> approaches: VLAN oriented basically.
>> 
>> Regards
>> Diego
>> 
>> -
>> Diego Parrilla
>> nubeblog.com | nubeb...@nubeblog.com | twitter.com/nubeblog
>> +34 649 94 43 29
>> 
>> 
>> 
>> 
>> On Thu, Feb 3, 2011 at 2:37 AM, Monsyne Dragon 
>> wrote:
>>> I am sorting out some possible implementations for the
>>> multi-tenant-accounting blueprint, and the related system-usage-records
>>> bp,
>>> and I just wanted to run this by anyone interested in such matters.
>>> 
>>> Basically, for multitenant purposes we need to introduce the concept of
>>> an
>>> 'account' in nova, representing a customer,  that basically acts as a
>>> label
>>> for a group of resources (instances, etc), and for access control (i.e
>>> customer a cannot mess w/ customer b's stuff)
>>> 
>>> There was some confusion on how best to implement this, in relation to
>>> nova's project concept.  Projects are kind of like what we want an
>>> account
>>> to be, but there are some associations (like one project per network)
>>> which
>>> are not valid for our flat networking setup.  I am kind of
>>> straw-polling on
>>> which is better here:
>>> 
>>> The options are:
>>> 1) Create a new 'account' concept in nova,  with an account basically
>>> being
>>> a subgroup of a project (providers would use a single, default project,
>>> with
>>> additional projects added if needed for separate brands, or resellers,
>>> etc),
>>> add in access control per account as well as project, and make sure
>>> apis/auth specify account appropriately,  have some way for a default
>>> account to used (per project) so account doesn't get in the way for
>>> non-multitenant users.
>>> 
>>> 2) having account == nova's "project", and changing the network
>>> associations, etc so projects can support our model (as well as current
>>> models).  Support for associating accounts (projects) together for
>>> resellers, etc would either be delegated outside of nova or added later
>>> (it's not a current requirement).
>>> 
>>> In either case, accounts would be identified by name, which would  be an
>>> opaque string an outside system/person would assign, and could
>>> structure to
>>> their needs (ie. for associating accounts with common prefixes, etc)
>>> 
>>> --
>>> 
>>> --
>>>   -Monsyne Dragon
>>>   work: 210-312-4190
>>>   mobile210-441-0965
>>>   google voice: 210-338-0336
>>> 
>>> 
>>> 
>>> 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 ab...@rackspace.com, and delete the original message.
>>> Your cooperation is appreciated.
>>> 
>>> 
>>> ___
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to : ope

Re: [Openstack] Pondering multi-tenant needs in nova.

[John Purrier]

I think Glen is on the right track here. Having the account_ID be a string
with no connotation for Nova allows two benefits: 1) deployments can create
the arbitrary organizational models that fit their particular DC, physical,
and logical structures, and 2) the Nova code is simpler as the hierarchical
concepts do not have any manifestations in the code.

 

Additional benefit includes an easier mapping to the particular identity and
authorization system that a deployment chooses to use.

 

John

 

From: openstack-bounces+john=openstack@lists.launchpad.net
[mailto:openstack-bounces+john=openstack@lists.launchpad.net] On Behalf
Of Glen Campbell
Sent: Thursday, February 03, 2011 2:42 PM
To: Devin Carlen; Monsyne Dragon
Cc: openstack@lists.launchpad.net
Subject: Re: [Openstack] Pondering multi-tenant needs in nova.

 

I think that this could be done in the current proposal. Specifically, the
account_id is an arbitrary string that is generated externally to Nova. You
could, for example, easily identify an organizational hierarchy. For
example, an accountID could be:

 

enterprise-org-project-milestone

 

>From Nova's point of view, it makes no difference, so long as that string is
associated with a usage event and regurgitated when reported. The cloud
administrator can interpret it however it chooses. For simple organizations,
it could be identical to the project_id, or even just blank. The project_id
holds the network information, and the account_id tracks the usage and other
notifications.

 

There's no good reason for Nova to have to model an organization internally;
it certainly wouldn't match all the possible org structures available. 

 

 

 

From: Devin Carlen 
Date: Thu, 3 Feb 2011 12:02:38 -0800
To: Monsyne Dragon 
Cc: 
Subject: Re: [Openstack] Pondering multi-tenant needs in nova.

 

We were just talking about this the other day.  We definitely need some kind
of further hierarchy.  I think a typical kind of use case for multi-tenant
could be something like:

 

Enterprise contains Organizations

 

Organizations contain Organizations and Projects

 

Projects contain Instances, etc.

 

 

In this structure enterprise is just a top level organization.  If we
structure it this way it would make metering and billing pretty simple.

 

 

 

 

 

 

On Feb 2, 2011, at 5:37 PM, Monsyne Dragon wrote:

 

I am sorting out some possible implementations for the
multi-tenant-accounting blueprint, and the related system-usage-records bp,
and I just wanted to run this by anyone interested in such matters.

Basically, for multitenant purposes we need to introduce the concept of an
'account' in nova, representing a customer,  that basically acts as a label
for a group of resources (instances, etc), and for access control (i.e
customer a cannot mess w/ customer b's stuff)

There was some confusion on how best to implement this, in relation to
nova's project concept.  Projects are kind of like what we want an account
to be, but there are some associations (like one project per network) which
are not valid for our flat networking setup.  I am kind of straw-polling on
which is better here:

The options are:
1) Create a new 'account' concept in nova,  with an account basically being
a subgroup of a project (providers would use a single, default project, with
additional projects added if needed for separate brands, or resellers, etc),
add in access control per account as well as project, and make sure
apis/auth specify account appropriately,  have some way for a default
account to used (per project) so account doesn't get in the way for
non-multitenant users.

2) having account == nova's "project", and changing the network
associations, etc so projects can support our model (as well as current
models).  Support for associating accounts (projects) together for
resellers, etc would either be delegated outside of nova or added later
(it's not a current requirement).

In either case, accounts would be identified by name, which would  be an
opaque string an outside system/person would assign, and could structure to
their needs (ie. for associating accounts with common prefixes, etc)

-- 

--
   -Monsyne Dragon
   work: 210-312-4190
   mobile210-441-0965
   google voice: 210-338-0336



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 ab...@rackspace.com, and delete the original message.
Your cooperation is appreciated.


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : http

Re: [Openstack] Pondering multi-tenant needs in nova.

[Monsyne Dragon]

On 2/3/11 2:02 PM, Devin Carlen wrote:
We were just talking about this the other day.  We definitely need 
some kind of further hierarchy.  I think a typical kind of use case 
for multi-tenant could be something like:


Enterprise contains Organizations

Organizations contain Organizations and Projects

Projects contain Instances, etc.


In this structure enterprise is just a top level organization.  If we 
structure it this way it would make metering and billing pretty simple.
Yah, we are trying to avoid getting  too deep into into organizational 
structure with the multitenant stuff atm.  At the previous summit we 
were talking about using a pretty flat structure, basically 'accounts' 
for grouping instances, with a flexible naming scheme, and leave the 
hierarchy management as being something outside the scope of Nova, which 
would be taken care of by other systems (since each nova implementer is 
likely to have very different needs and ideas on how to do that. ).  
Since the account names would be opaque strings to Nova, if an outside 
system wanted to use account names like  
"JoeCorp:usdivision:hr:recruiting" it could.


The main decision we are making here is, do we implement accounts as 
projects (in which case we need to make projects able to share networks 
to support our model) or do we add a new account concept (in which case, 
Rackspace, and others using similar org models, will pretty much ignore 
the "project"  concept, just using a single 'default' project).






On Feb 2, 2011, at 5:37 PM, Monsyne Dragon wrote:

I am sorting out some possible implementations for the 
multi-tenant-accounting blueprint, and the related 
system-usage-records bp,

and I just wanted to run this by anyone interested in such matters.

Basically, for multitenant purposes we need to introduce the concept 
of an 'account' in nova, representing a customer,  that basically 
acts as a label for a group of resources (instances, etc), and for 
access control (i.e customer a cannot mess w/ customer b's stuff)


There was some confusion on how best to implement this, in relation 
to nova's project concept.  Projects are kind of like what we want an 
account to be, but there are some associations (like one project per 
network) which are not valid for our flat networking setup.  I am 
kind of straw-polling on which is better here:


The options are:
1) Create a new 'account' concept in nova,  with an account basically 
being a subgroup of a project (providers would use a single, default 
project, with additional projects added if needed for separate 
brands, or resellers, etc), add in access control per account as well 
as project, and make sure apis/auth specify account appropriately, 
 have some way for a default account to used (per project) so account 
doesn't get in the way for non-multitenant users.


2) having account == nova's "project", and changing the network 
associations, etc so projects can support our model (as well as 
current models).  Support for associating accounts (projects) 
together for resellers, etc would either be delegated outside of nova 
or added later (it's not a current requirement).


In either case, accounts would be identified by name, which would  be 
an opaque string an outside system/person would assign, and could 
structure to their needs (ie. for associating accounts with common 
prefixes, etc)


--

--
   -Monsyne Dragon
   work: 210-312-4190
   mobile210-441-0965
   google voice: 210-338-0336



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 ab...@rackspace.com , and delete the 
original message.

Your cooperation is appreciated.


___
Mailing list: https://launchpad.net/~openstack 

Post to : openstack@lists.launchpad.net 

Unsubscribe : https://launchpad.net/~openstack 


More help   : https://help.launchpad.net/ListHelp





--

--
-Monsyne Dragon
work: 210-312-4190
mobile210-441-0965
google voice: 210-338-0336



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 transmissio

Re: [Openstack] Pondering multi-tenant needs in nova.

[Brian Lamar]

Would a less structured approach work to make billing/reporting more flexible 
for the community? I was thinking something along the lines of tags. With an 
arbitrary set of tags, instances could have a tag saying they belong to a 
certain organisation and/or an enterprise. 

Reports could be generated collecting the number of instances with a specific 
tag and it would allow for potentially arbitrary billing patterns. 

I'll admit to being surprised at myself advocating for arbitrary tags, but 
having worked on billing systems in the past...the last thing I'd like is for a 
rigid hierarchy to be put in, because right after it's done it's inevitable 
that another part of the company wants to change how customers are billed.

B

-Original Message-
From: "Devin Carlen" 
Sent: Thursday, February 3, 2011 3:02pm
To: "Monsyne Dragon" 
Cc: openstack@lists.launchpad.net
Subject: Re: [Openstack] Pondering multi-tenant needs in nova.

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp
We were just talking about this the other day.  We definitely need some kind of 
further hierarchy.  I think a typical kind of use case for multi-tenant could 
be something like:

Enterprise contains Organizations

Organizations contain Organizations and Projects

Projects contain Instances, etc.


In this structure enterprise is just a top level organization.  If we structure 
it this way it would make metering and billing pretty simple.



 


On Feb 2, 2011, at 5:37 PM, Monsyne Dragon wrote:

> I am sorting out some possible implementations for the 
> multi-tenant-accounting blueprint, and the related system-usage-records bp,
> and I just wanted to run this by anyone interested in such matters.
> 
> Basically, for multitenant purposes we need to introduce the concept of an 
> 'account' in nova, representing a customer,  that basically acts as a label 
> for a group of resources (instances, etc), and for access control (i.e 
> customer a cannot mess w/ customer b's stuff)
> 
> There was some confusion on how best to implement this, in relation to nova's 
> project concept.  Projects are kind of like what we want an account to be, 
> but there are some associations (like one project per network) which are not 
> valid for our flat networking setup.  I am kind of straw-polling on which is 
> better here:
> 
> The options are:
> 1) Create a new 'account' concept in nova,  with an account basically being a 
> subgroup of a project (providers would use a single, default project, with 
> additional projects added if needed for separate brands, or resellers, etc), 
> add in access control per account as well as project, and make sure apis/auth 
> specify account appropriately,  have some way for a default account to used 
> (per project) so account doesn't get in the way for non-multitenant users.
> 
> 2) having account == nova's "project", and changing the network associations, 
> etc so projects can support our model (as well as current models).  Support 
> for associating accounts (projects) together for resellers, etc would either 
> be delegated outside of nova or added later (it's not a current requirement).
> 
> In either case, accounts would be identified by name, which would  be an 
> opaque string an outside system/person would assign, and could structure to 
> their needs (ie. for associating accounts with common prefixes, etc)
> 
> -- 
> 
> --
>-Monsyne Dragon
>work: 210-312-4190
>mobile210-441-0965
>google voice: 210-338-0336
> 
> 
> 
> 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 ab...@rackspace.com, and delete the original message.
> Your cooperation is appreciated.
> 
> 
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp




___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Pondering multi-tenant needs in nova.

[Sandy Walsh]

> There's no good reason for Nova to have to model an organization internally; 
> it certainly wouldn't match all the possible org structures available.

+1



From: Devin Carlen mailto:devin.car...@gmail.com>>
Date: Thu, 3 Feb 2011 12:02:38 -0800
To: Monsyne Dragon mailto:mdra...@rackspace.com>>
Cc: mailto:openstack@lists.launchpad.net>>
Subject: Re: [Openstack] Pondering multi-tenant needs in nova.

We were just talking about this the other day.  We definitely need some kind of 
further hierarchy.  I think a typical kind of use case for multi-tenant could 
be something like:

Enterprise contains Organizations

Organizations contain Organizations and Projects

Projects contain Instances, etc.


In this structure enterprise is just a top level organization.  If we structure 
it this way it would make metering and billing pretty simple.






On Feb 2, 2011, at 5:37 PM, Monsyne Dragon wrote:

I am sorting out some possible implementations for the multi-tenant-accounting 
blueprint, and the related system-usage-records bp,
and I just wanted to run this by anyone interested in such matters.

Basically, for multitenant purposes we need to introduce the concept of an 
'account' in nova, representing a customer,  that basically acts as a label for 
a group of resources (instances, etc), and for access control (i.e customer a 
cannot mess w/ customer b's stuff)

There was some confusion on how best to implement this, in relation to nova's 
project concept.  Projects are kind of like what we want an account to be, but 
there are some associations (like one project per network) which are not valid 
for our flat networking setup.  I am kind of straw-polling on which is better 
here:

The options are:
1) Create a new 'account' concept in nova,  with an account basically being a 
subgroup of a project (providers would use a single, default project, with 
additional projects added if needed for separate brands, or resellers, etc), 
add in access control per account as well as project, and make sure apis/auth 
specify account appropriately,  have some way for a default account to used 
(per project) so account doesn't get in the way for non-multitenant users.

2) having account == nova's "project", and changing the network associations, 
etc so projects can support our model (as well as current models).  Support for 
associating accounts (projects) together for resellers, etc would either be 
delegated outside of nova or added later (it's not a current requirement).

In either case, accounts would be identified by name, which would  be an opaque 
string an outside system/person would assign, and could structure to their 
needs (ie. for associating accounts with common prefixes, etc)

--

--
   -Monsyne Dragon
   work: 210-312-4190
   mobile210-441-0965
   google voice: 210-338-0336



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 ab...@rackspace.com, and delete the original 
message.
Your cooperation is appreciated.


___
Mailing list: https://launchpad.net/~openstack
Post to : 
openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

___ Mailing list: 
https://launchpad.net/~openstack Post to : 
openstack@lists.launchpad.net Unsubscribe 
: https://launchpad.net/~openstack More help : 
https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Pondering multi-tenant needs in nova.

[Diego Parrilla Santamaría]

Sandy, Devin,

this is structure we had in my former cloud platform to fit easily in
a LDAP. It also helped in metering.

Diego

-
Diego Parrilla
nubeblog.com | nubeb...@nubeblog.com | twitter.com/nubeblog
+34 649 94 43 29




On Thu, Feb 3, 2011 at 9:29 PM, Sandy Walsh  wrote:
> Sounds very LDAP.
> Would it make sense to have a plug-in so we could mimic a pre-existing corp
> LDAP structure?
> -S
>
> 
> From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net
> [openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net] on behalf
> of Devin Carlen [devin.car...@gmail.com]
> Sent: Thursday, February 03, 2011 4:02 PM
> To: Monsyne Dragon
> Cc: openstack@lists.launchpad.net
> Subject: Re: [Openstack] Pondering multi-tenant needs in nova.
>
> We were just talking about this the other day.  We definitely need some kind
> of further hierarchy.  I think a typical kind of use case for multi-tenant
> could be something like:
> Enterprise contains Organizations
> Organizations contain Organizations and Projects
> Projects contain Instances, etc.
>
> In this structure enterprise is just a top level organization.  If we
> structure it this way it would make metering and billing pretty simple.
>
>
>
>
> On Feb 2, 2011, at 5:37 PM, Monsyne Dragon wrote:
>
> I am sorting out some possible implementations for the
> multi-tenant-accounting blueprint, and the related system-usage-records bp,
> and I just wanted to run this by anyone interested in such matters.
>
> Basically, for multitenant purposes we need to introduce the concept of an
> 'account' in nova, representing a customer,  that basically acts as a label
> for a group of resources (instances, etc), and for access control (i.e
> customer a cannot mess w/ customer b's stuff)
>
> There was some confusion on how best to implement this, in relation to
> nova's project concept.  Projects are kind of like what we want an account
> to be, but there are some associations (like one project per network) which
> are not valid for our flat networking setup.  I am kind of straw-polling on
> which is better here:
>
> The options are:
> 1) Create a new 'account' concept in nova,  with an account basically being
> a subgroup of a project (providers would use a single, default project, with
> additional projects added if needed for separate brands, or resellers, etc),
> add in access control per account as well as project, and make sure
> apis/auth specify account appropriately,  have some way for a default
> account to used (per project) so account doesn't get in the way for
> non-multitenant users.
>
> 2) having account == nova's "project", and changing the network
> associations, etc so projects can support our model (as well as current
> models).  Support for associating accounts (projects) together for
> resellers, etc would either be delegated outside of nova or added later
> (it's not a current requirement).
>
> In either case, accounts would be identified by name, which would  be an
> opaque string an outside system/person would assign, and could structure to
> their needs (ie. for associating accounts with common prefixes, etc)
>
> --
>
> --
>    -Monsyne Dragon
>    work: 210-312-4190
>    mobile    210-441-0965
>    google voice: 210-338-0336
>
>
>
> 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 ab...@rackspace.com, and delete the original message.
> Your cooperation is appreciated.
>
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Pondering multi-tenant needs in nova.

[Glen Campbell]

I think that this could be done in the current proposal. Specifically, the 
account_id is an arbitrary string that is generated externally to Nova. You 
could, for example, easily identify an organizational hierarchy. For example, 
an accountID could be:

enterprise-org-project-milestone

>From Nova's point of view, it makes no difference, so long as that string is 
>associated with a usage event and regurgitated when reported. The cloud 
>administrator can interpret it however it chooses. For simple organizations, 
>it could be identical to the project_id, or even just blank. The project_id 
>holds the network information, and the account_id tracks the usage and other 
>notifications.

There's no good reason for Nova to have to model an organization internally; it 
certainly wouldn't match all the possible org structures available.



From: Devin Carlen mailto:devin.car...@gmail.com>>
Date: Thu, 3 Feb 2011 12:02:38 -0800
To: Monsyne Dragon mailto:mdra...@rackspace.com>>
Cc: mailto:openstack@lists.launchpad.net>>
Subject: Re: [Openstack] Pondering multi-tenant needs in nova.

We were just talking about this the other day.  We definitely need some kind of 
further hierarchy.  I think a typical kind of use case for multi-tenant could 
be something like:

Enterprise contains Organizations

Organizations contain Organizations and Projects

Projects contain Instances, etc.


In this structure enterprise is just a top level organization.  If we structure 
it this way it would make metering and billing pretty simple.






On Feb 2, 2011, at 5:37 PM, Monsyne Dragon wrote:

I am sorting out some possible implementations for the multi-tenant-accounting 
blueprint, and the related system-usage-records bp,
and I just wanted to run this by anyone interested in such matters.

Basically, for multitenant purposes we need to introduce the concept of an 
'account' in nova, representing a customer,  that basically acts as a label for 
a group of resources (instances, etc), and for access control (i.e customer a 
cannot mess w/ customer b's stuff)

There was some confusion on how best to implement this, in relation to nova's 
project concept.  Projects are kind of like what we want an account to be, but 
there are some associations (like one project per network) which are not valid 
for our flat networking setup.  I am kind of straw-polling on which is better 
here:

The options are:
1) Create a new 'account' concept in nova,  with an account basically being a 
subgroup of a project (providers would use a single, default project, with 
additional projects added if needed for separate brands, or resellers, etc), 
add in access control per account as well as project, and make sure apis/auth 
specify account appropriately,  have some way for a default account to used 
(per project) so account doesn't get in the way for non-multitenant users.

2) having account == nova's "project", and changing the network associations, 
etc so projects can support our model (as well as current models).  Support for 
associating accounts (projects) together for resellers, etc would either be 
delegated outside of nova or added later (it's not a current requirement).

In either case, accounts would be identified by name, which would  be an opaque 
string an outside system/person would assign, and could structure to their 
needs (ie. for associating accounts with common prefixes, etc)

--

--
   -Monsyne Dragon
   work: 210-312-4190
   mobile210-441-0965
   google voice: 210-338-0336



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 ab...@rackspace.com, and delete the original 
message.
Your cooperation is appreciated.


___
Mailing list: https://launchpad.net/~openstack
Post to : 
openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

___ Mailing list: 
https://launchpad.net/~openstack Post to : 
openstack@lists.launchpad.net Unsubscribe 
: https://launchpad.net/~openstack More help : 
https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Pondering multi-tenant needs in nova.

[Sandy Walsh]

Sounds very LDAP.

Would it make sense to have a plug-in so we could mimic a pre-existing corp 
LDAP structure?

-S


From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net 
[openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net] on behalf of 
Devin Carlen [devin.car...@gmail.com]
Sent: Thursday, February 03, 2011 4:02 PM
To: Monsyne Dragon
Cc: openstack@lists.launchpad.net
Subject: Re: [Openstack] Pondering multi-tenant needs in nova.

We were just talking about this the other day.  We definitely need some kind of 
further hierarchy.  I think a typical kind of use case for multi-tenant could 
be something like:

Enterprise contains Organizations

Organizations contain Organizations and Projects

Projects contain Instances, etc.


In this structure enterprise is just a top level organization.  If we structure 
it this way it would make metering and billing pretty simple.






On Feb 2, 2011, at 5:37 PM, Monsyne Dragon wrote:

I am sorting out some possible implementations for the multi-tenant-accounting 
blueprint, and the related system-usage-records bp,
and I just wanted to run this by anyone interested in such matters.

Basically, for multitenant purposes we need to introduce the concept of an 
'account' in nova, representing a customer,  that basically acts as a label for 
a group of resources (instances, etc), and for access control (i.e customer a 
cannot mess w/ customer b's stuff)

There was some confusion on how best to implement this, in relation to nova's 
project concept.  Projects are kind of like what we want an account to be, but 
there are some associations (like one project per network) which are not valid 
for our flat networking setup.  I am kind of straw-polling on which is better 
here:

The options are:
1) Create a new 'account' concept in nova,  with an account basically being a 
subgroup of a project (providers would use a single, default project, with 
additional projects added if needed for separate brands, or resellers, etc), 
add in access control per account as well as project, and make sure apis/auth 
specify account appropriately,  have some way for a default account to used 
(per project) so account doesn't get in the way for non-multitenant users.

2) having account == nova's "project", and changing the network associations, 
etc so projects can support our model (as well as current models).  Support for 
associating accounts (projects) together for resellers, etc would either be 
delegated outside of nova or added later (it's not a current requirement).

In either case, accounts would be identified by name, which would  be an opaque 
string an outside system/person would assign, and could structure to their 
needs (ie. for associating accounts with common prefixes, etc)

--

--
   -Monsyne Dragon
   work: 210-312-4190
   mobile210-441-0965
   google voice: 210-338-0336



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 ab...@rackspace.com, and delete the original 
message.
Your cooperation is appreciated.


___
Mailing list: https://launchpad.net/~openstack
Post to : 
openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Pondering multi-tenant needs in nova.

[Devin Carlen]

We were just talking about this the other day.  We definitely need some kind of 
further hierarchy.  I think a typical kind of use case for multi-tenant could 
be something like:

Enterprise contains Organizations

Organizations contain Organizations and Projects

Projects contain Instances, etc.


In this structure enterprise is just a top level organization.  If we structure 
it this way it would make metering and billing pretty simple.



 


On Feb 2, 2011, at 5:37 PM, Monsyne Dragon wrote:

> I am sorting out some possible implementations for the 
> multi-tenant-accounting blueprint, and the related system-usage-records bp,
> and I just wanted to run this by anyone interested in such matters.
> 
> Basically, for multitenant purposes we need to introduce the concept of an 
> 'account' in nova, representing a customer,  that basically acts as a label 
> for a group of resources (instances, etc), and for access control (i.e 
> customer a cannot mess w/ customer b's stuff)
> 
> There was some confusion on how best to implement this, in relation to nova's 
> project concept.  Projects are kind of like what we want an account to be, 
> but there are some associations (like one project per network) which are not 
> valid for our flat networking setup.  I am kind of straw-polling on which is 
> better here:
> 
> The options are:
> 1) Create a new 'account' concept in nova,  with an account basically being a 
> subgroup of a project (providers would use a single, default project, with 
> additional projects added if needed for separate brands, or resellers, etc), 
> add in access control per account as well as project, and make sure apis/auth 
> specify account appropriately,  have some way for a default account to used 
> (per project) so account doesn't get in the way for non-multitenant users.
> 
> 2) having account == nova's "project", and changing the network associations, 
> etc so projects can support our model (as well as current models).  Support 
> for associating accounts (projects) together for resellers, etc would either 
> be delegated outside of nova or added later (it's not a current requirement).
> 
> In either case, accounts would be identified by name, which would  be an 
> opaque string an outside system/person would assign, and could structure to 
> their needs (ie. for associating accounts with common prefixes, etc)
> 
> -- 
> 
> --
>-Monsyne Dragon
>work: 210-312-4190
>mobile210-441-0965
>google voice: 210-338-0336
> 
> 
> 
> 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 ab...@rackspace.com, and delete the original message.
> Your cooperation is appreciated.
> 
> 
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Pondering multi-tenant needs in nova.

[Carl Fischer]

Right, I actually meant to say remains a first class citizen, agreeing
with Diego as an adjunct to Paul's comment in case anyone interpreted his
100% valid point as a ding against the VLAN model.

Carl 

On 2/3/11 12:35 PM, "Jay Pipes"  wrote:

>If I'm not mistaken, VLAN networking *is* a first class citizen in
>Nova. It's the Flat Networking model which isn't a first-class
>citizen, and thus the need for support in things such as this:
>
>IPv6 is not supported in FlatManager network mode.
>You can't use FlatDHCPManager network mode on a multiple machines
>deployment without using multiple interfaces (Bug 710959). Recommended
>mode of operation for deploying Nova on multiple machines is to use
>VLAN-supporting managed switches with VlanManager network mode.
>
>^^ is from the Bexar release notes.
>
>-jay
>
>2011/2/3 Carl Fischer :
>> Diego is definitely correct. The drawbacks with VLANs are well
>>documented
>> but they remain the primary solution for providing per-tenant L2 domains
>> for many shops today, due to skill set, comfort level, etc. The
>> L3-integrated solutions on the horizon will be vast improvements, but
>> until they arrive/mature we need to ensure the VLAN model is a first
>>class
>> citizen.
>>
>> Carl
>> Citrix Systems
>> carl.fisc...@citrix.com
>>
>> On 2/3/11 6:32 AM, "Diego Parrilla Santamaría"
>>  wrote:
>>
>>>Thanks Paul. Your explanation really helps. A vlan is a scarce
>>>resource in cloud infraestructures and most of the people don't know
>>>about it.
>>>
>>>I asked about this topic in this thread because I see two different
>>>approaches that colides. And can have a huge impact in the 'account'
>>>entity.
>>>
>>>The truth is that most of the datacenter professionals I have talked
>>>about reject the Flat Network model and embrace the VLAN (or more than
>>>one VLAN) per customer model because it is what they know and they
>>>feel 'secured' using them. Openstack let us choose what model to use,
>>>and this great and I think should not change. So, creating an account
>>>entitty directly linked to the network model is dangerous because it
>>>can limit this flexibility.
>>>
>>>I know, I have not given any valid answer... but it's something to
>>>consider due to the efforts to support a more complex network
>>>management.
>>>
>>>Cheers
>>>Diego
>>>
>>>-
>>>Diego Parrilla
>>>nubeblog.com | nubeb...@nubeblog.com | twitter.com/nubeblog
>>>+34 649 94 43 29
>>>
>>>
>>>
>>>
>>>2011/2/3 Paul Voccio :
 Diego,

 Due to our networking topology, having a vlan per customer isn't
really
 feasible. Most switches are limited at 4k or 8k or even 32k. With more
 customers than these switches can reasonably accommodate, having a
single
 vlan per customer either limits the portability within a cloud or
limits
 the scale at which you can build your cloud. Open vSwitch will
alleviate
 some of this pain, but until we get it in XenServer, we're somewhat
stuck
 on flat networking.

 Paul

 On 2/3/11 4:20 AM, "Diego Parrilla Santamaría"
  wrote:

>Hi Monsyne,
>
>it's a very interesting topic and I'm curious about the reason why you
>are using the Flat Networking set up. From the conversations in other
>threads it seems the Service Providers prefer different networking
>approaches: VLAN oriented basically.
>
>Regards
>Diego
>
>-
>Diego Parrilla
>nubeblog.com | nubeb...@nubeblog.com | twitter.com/nubeblog
>+34 649 94 43 29
>
>
>
>
>On Thu, Feb 3, 2011 at 2:37 AM, Monsyne Dragon 
>wrote:
>> I am sorting out some possible implementations for the
>> multi-tenant-accounting blueprint, and the related
>>system-usage-records
>>bp,
>> and I just wanted to run this by anyone interested in such matters.
>>
>> Basically, for multitenant purposes we need to introduce the concept
>>of
>>an
>> 'account' in nova, representing a customer,  that basically acts as
>>a
>>label
>> for a group of resources (instances, etc), and for access control
>>(i.e
>> customer a cannot mess w/ customer b's stuff)
>>
>> There was some confusion on how best to implement this, in relation
>>to
>> nova's project concept.  Projects are kind of like what we want an
>>account
>> to be, but there are some associations (like one project per
>>network)
>>which
>> are not valid for our flat networking setup.  I am kind of
>>straw-polling on
>> which is better here:
>>
>> The options are:
>> 1) Create a new 'account' concept in nova,  with an account
>>basically
>>being
>> a subgroup of a project (providers would use a single, default
>>project,
>>with
>> additional projects added if needed for separate brands, or
>>resellers,
>>etc),
>> add in access control per account as well as project, and make sure
>> apis/auth specify account appropriate

Re: [Openstack] Pondering multi-tenant needs in nova.

[Jay Pipes]

If I'm not mistaken, VLAN networking *is* a first class citizen in
Nova. It's the Flat Networking model which isn't a first-class
citizen, and thus the need for support in things such as this:

IPv6 is not supported in FlatManager network mode.
You can't use FlatDHCPManager network mode on a multiple machines
deployment without using multiple interfaces (Bug 710959). Recommended
mode of operation for deploying Nova on multiple machines is to use
VLAN-supporting managed switches with VlanManager network mode.

^^ is from the Bexar release notes.

-jay

2011/2/3 Carl Fischer :
> Diego is definitely correct. The drawbacks with VLANs are well documented
> but they remain the primary solution for providing per-tenant L2 domains
> for many shops today, due to skill set, comfort level, etc. The
> L3-integrated solutions on the horizon will be vast improvements, but
> until they arrive/mature we need to ensure the VLAN model is a first class
> citizen.
>
> Carl
> Citrix Systems
> carl.fisc...@citrix.com
>
> On 2/3/11 6:32 AM, "Diego Parrilla Santamaría"
>  wrote:
>
>>Thanks Paul. Your explanation really helps. A vlan is a scarce
>>resource in cloud infraestructures and most of the people don't know
>>about it.
>>
>>I asked about this topic in this thread because I see two different
>>approaches that colides. And can have a huge impact in the 'account'
>>entity.
>>
>>The truth is that most of the datacenter professionals I have talked
>>about reject the Flat Network model and embrace the VLAN (or more than
>>one VLAN) per customer model because it is what they know and they
>>feel 'secured' using them. Openstack let us choose what model to use,
>>and this great and I think should not change. So, creating an account
>>entitty directly linked to the network model is dangerous because it
>>can limit this flexibility.
>>
>>I know, I have not given any valid answer... but it's something to
>>consider due to the efforts to support a more complex network
>>management.
>>
>>Cheers
>>Diego
>>
>>-
>>Diego Parrilla
>>nubeblog.com | nubeb...@nubeblog.com | twitter.com/nubeblog
>>+34 649 94 43 29
>>
>>
>>
>>
>>2011/2/3 Paul Voccio :
>>> Diego,
>>>
>>> Due to our networking topology, having a vlan per customer isn't really
>>> feasible. Most switches are limited at 4k or 8k or even 32k. With more
>>> customers than these switches can reasonably accommodate, having a
>>>single
>>> vlan per customer either limits the portability within a cloud or limits
>>> the scale at which you can build your cloud. Open vSwitch will alleviate
>>> some of this pain, but until we get it in XenServer, we're somewhat
>>>stuck
>>> on flat networking.
>>>
>>> Paul
>>>
>>> On 2/3/11 4:20 AM, "Diego Parrilla Santamaría"
>>>  wrote:
>>>
Hi Monsyne,

it's a very interesting topic and I'm curious about the reason why you
are using the Flat Networking set up. From the conversations in other
threads it seems the Service Providers prefer different networking
approaches: VLAN oriented basically.

Regards
Diego

-
Diego Parrilla
nubeblog.com | nubeb...@nubeblog.com | twitter.com/nubeblog
+34 649 94 43 29




On Thu, Feb 3, 2011 at 2:37 AM, Monsyne Dragon 
wrote:
> I am sorting out some possible implementations for the
> multi-tenant-accounting blueprint, and the related
>system-usage-records
>bp,
> and I just wanted to run this by anyone interested in such matters.
>
> Basically, for multitenant purposes we need to introduce the concept
>of
>an
> 'account' in nova, representing a customer,  that basically acts as a
>label
> for a group of resources (instances, etc), and for access control (i.e
> customer a cannot mess w/ customer b's stuff)
>
> There was some confusion on how best to implement this, in relation to
> nova's project concept.  Projects are kind of like what we want an
>account
> to be, but there are some associations (like one project per network)
>which
> are not valid for our flat networking setup.  I am kind of
>straw-polling on
> which is better here:
>
> The options are:
> 1) Create a new 'account' concept in nova,  with an account basically
>being
> a subgroup of a project (providers would use a single, default
>project,
>with
> additional projects added if needed for separate brands, or resellers,
>etc),
> add in access control per account as well as project, and make sure
> apis/auth specify account appropriately,  have some way for a default
> account to used (per project) so account doesn't get in the way for
> non-multitenant users.
>
> 2) having account == nova's "project", and changing the network
> associations, etc so projects can support our model (as well as
>current
> models).  Support for associating accounts (projects) together for
> resellers, etc would either be delegated outside of no

Re: [Openstack] Pondering multi-tenant needs in nova.

[Carl Fischer]

Diego is definitely correct. The drawbacks with VLANs are well documented
but they remain the primary solution for providing per-tenant L2 domains
for many shops today, due to skill set, comfort level, etc. The
L3-integrated solutions on the horizon will be vast improvements, but
until they arrive/mature we need to ensure the VLAN model is a first class
citizen.

Carl
Citrix Systems
carl.fisc...@citrix.com

On 2/3/11 6:32 AM, "Diego Parrilla Santamaría"
 wrote:

>Thanks Paul. Your explanation really helps. A vlan is a scarce
>resource in cloud infraestructures and most of the people don't know
>about it.
>
>I asked about this topic in this thread because I see two different
>approaches that colides. And can have a huge impact in the 'account'
>entity.
>
>The truth is that most of the datacenter professionals I have talked
>about reject the Flat Network model and embrace the VLAN (or more than
>one VLAN) per customer model because it is what they know and they
>feel 'secured' using them. Openstack let us choose what model to use,
>and this great and I think should not change. So, creating an account
>entitty directly linked to the network model is dangerous because it
>can limit this flexibility.
>
>I know, I have not given any valid answer... but it's something to
>consider due to the efforts to support a more complex network
>management.
>
>Cheers
>Diego
>
>-
>Diego Parrilla
>nubeblog.com | nubeb...@nubeblog.com | twitter.com/nubeblog
>+34 649 94 43 29
>
>
>
>
>2011/2/3 Paul Voccio :
>> Diego,
>>
>> Due to our networking topology, having a vlan per customer isn't really
>> feasible. Most switches are limited at 4k or 8k or even 32k. With more
>> customers than these switches can reasonably accommodate, having a
>>single
>> vlan per customer either limits the portability within a cloud or limits
>> the scale at which you can build your cloud. Open vSwitch will alleviate
>> some of this pain, but until we get it in XenServer, we're somewhat
>>stuck
>> on flat networking.
>>
>> Paul
>>
>> On 2/3/11 4:20 AM, "Diego Parrilla Santamaría"
>>  wrote:
>>
>>>Hi Monsyne,
>>>
>>>it's a very interesting topic and I'm curious about the reason why you
>>>are using the Flat Networking set up. From the conversations in other
>>>threads it seems the Service Providers prefer different networking
>>>approaches: VLAN oriented basically.
>>>
>>>Regards
>>>Diego
>>>
>>>-
>>>Diego Parrilla
>>>nubeblog.com | nubeb...@nubeblog.com | twitter.com/nubeblog
>>>+34 649 94 43 29
>>>
>>>
>>>
>>>
>>>On Thu, Feb 3, 2011 at 2:37 AM, Monsyne Dragon 
>>>wrote:
 I am sorting out some possible implementations for the
 multi-tenant-accounting blueprint, and the related
system-usage-records
bp,
 and I just wanted to run this by anyone interested in such matters.

 Basically, for multitenant purposes we need to introduce the concept
of
an
 'account' in nova, representing a customer,  that basically acts as a
label
 for a group of resources (instances, etc), and for access control (i.e
 customer a cannot mess w/ customer b's stuff)

 There was some confusion on how best to implement this, in relation to
 nova's project concept.  Projects are kind of like what we want an
account
 to be, but there are some associations (like one project per network)
which
 are not valid for our flat networking setup.  I am kind of
straw-polling on
 which is better here:

 The options are:
 1) Create a new 'account' concept in nova,  with an account basically
being
 a subgroup of a project (providers would use a single, default
project,
with
 additional projects added if needed for separate brands, or resellers,
etc),
 add in access control per account as well as project, and make sure
 apis/auth specify account appropriately,  have some way for a default
 account to used (per project) so account doesn't get in the way for
 non-multitenant users.

 2) having account == nova's "project", and changing the network
 associations, etc so projects can support our model (as well as
current
 models).  Support for associating accounts (projects) together for
 resellers, etc would either be delegated outside of nova or added
later
 (it's not a current requirement).

 In either case, accounts would be identified by name, which would  be
an
 opaque string an outside system/person would assign, and could
structure to
 their needs (ie. for associating accounts with common prefixes, etc)

 --

 --
-Monsyne Dragon
work: 210-312-4190
mobile210-441-0965
google voice: 210-338-0336



 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

Re: [Openstack] Network Service for L2/L3 Network Infrastructure blueprint

[Jay Pipes]

++ on all below points :) There are few bugs or blueprints that
actually require a huge patch. Most things can be done in small
chunks, making sure each chunk doesn't break tests...

-jay

On Thu, Feb 3, 2011 at 10:03 AM, Ed Leafe  wrote:
> On Feb 3, 2011, at 9:33 AM, Ewan Mellor wrote:
>
>> Maybe we should normally do big-picture merges normally, but have an 
>> exception procedure for when we'd like them piecemeal.
>
>
>        I think the main differentiator should be if the partial merge can 
> stand on its own. IOW, with something like the logging change, the first 
> merge would include any code to support the new logging changes, but after 
> that, going through all the files that need to be updated to use this change 
> is mainly exhaustive busy work. Effectively, the single project could be 
> merged as:
>
> a) add changed logging code
> b) change a bunch of files to use new logging
> c) change a bunch more files to use new logging
> d) change a bunch more files to use new logging
> ... repeat in bite-size chunks
> z) final commit of changes.
>
>        This way, at any point, everything will continue to work; the only 
> "problem" is that some code will be using the new logging, and other will 
> continue to use the old logging.
>
>        The main advantage is that reviewers will avoid having to wade through 
> miles-long diffs. Having to go through diffs that are extremely long 
> increases the chance that the reviewers eyes may miss a typo or some other 
> problem.
>
>
>
> -- Ed Leafe
>
>
>
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Network Service for L2/L3 Network Infrastructure blueprint

[Ed Leafe]

On Feb 3, 2011, at 9:33 AM, Ewan Mellor wrote:

> Maybe we should normally do big-picture merges normally, but have an 
> exception procedure for when we'd like them piecemeal.


I think the main differentiator should be if the partial merge can 
stand on its own. IOW, with something like the logging change, the first merge 
would include any code to support the new logging changes, but after that, 
going through all the files that need to be updated to use this change is 
mainly exhaustive busy work. Effectively, the single project could be merged as:

a) add changed logging code
b) change a bunch of files to use new logging
c) change a bunch more files to use new logging
d) change a bunch more files to use new logging
... repeat in bite-size chunks
z) final commit of changes.

This way, at any point, everything will continue to work; the only 
"problem" is that some code will be using the new logging, and other will 
continue to use the old logging. 

The main advantage is that reviewers will avoid having to wade through 
miles-long diffs. Having to go through diffs that are extremely long increases 
the chance that the reviewers eyes may miss a typo or some other problem.



-- Ed Leafe




___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Network Service for L2/L3 Network Infrastructure blueprint

[Ewan Mellor]

> -Original Message-
> From: openstack-bounces+ewan.mellor=citrix@lists.launchpad.net
> [mailto:openstack-bounces+ewan.mellor=citrix@lists.launchpad.net]
> On Behalf Of Ed Leafe
> Sent: 03 February 2011 14:18
> To: openstack@lists.launchpad.net
> Subject: Re: [Openstack] Network Service for L2/L3 Network
> Infrastructure blueprint
> 
> On Feb 3, 2011, at 8:52 AM, Jay Pipes wrote:
> 
> >> Absolutely not, as long as we're not trying to merge conflicting
> branches.  That was the problem last time -- I18N and the logging
> changes in particular were such pervasive pieces of work that it was
> hard work merging all the time.  Hopefully we won't see the likes of
> those again for a little while!
> >
> > Hehe, understood. I did 6 or 7 merge trunks while dealing with i18n,
> > so I feel you :)  But, luckily, we don't look to have any of those
> > super-invasive blueprints on deck for Cactus...but you never know ;)
> 
> 
>   Is there any proscription about merging a partial change? IOW, if
> something like the logging change affected 100 files, would it be
> acceptable to merge, say, 20 at a time? As long as tests continue to
> pass, of course, and the merge prop is labeled as a partial
> implementation, and everything else continues to work without problem.
> This way any individual merge will only conflict with a few branches,
> while huge mega-merges will conflict with just about everything.

I'd much rather do small merges.  I'm a "commit-once, commit-often" man, for 
exactly this reason.

I think the objection was that it would be difficult to peer-review stuff if it 
was coming in piecemeal, because you don't get to see the big picture of the 
change.  That's a reasonable comment, and commit-once, commit-often does rely 
on the fact that you trust the person making all those commits.

Maybe we should normally do big-picture merges normally, but have an exception 
procedure for when we'd like them piecemeal.

Ewan.


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Pondering multi-tenant needs in nova.

[Diego Parrilla Santamaría]

Thanks Paul. Your explanation really helps. A vlan is a scarce
resource in cloud infraestructures and most of the people don't know
about it.

I asked about this topic in this thread because I see two different
approaches that colides. And can have a huge impact in the 'account'
entity.

The truth is that most of the datacenter professionals I have talked
about reject the Flat Network model and embrace the VLAN (or more than
one VLAN) per customer model because it is what they know and they
feel 'secured' using them. Openstack let us choose what model to use,
and this great and I think should not change. So, creating an account
entitty directly linked to the network model is dangerous because it
can limit this flexibility.

I know, I have not given any valid answer... but it's something to
consider due to the efforts to support a more complex network
management.

Cheers
Diego

-
Diego Parrilla
nubeblog.com | nubeb...@nubeblog.com | twitter.com/nubeblog
+34 649 94 43 29




2011/2/3 Paul Voccio :
> Diego,
>
> Due to our networking topology, having a vlan per customer isn't really
> feasible. Most switches are limited at 4k or 8k or even 32k. With more
> customers than these switches can reasonably accommodate, having a single
> vlan per customer either limits the portability within a cloud or limits
> the scale at which you can build your cloud. Open vSwitch will alleviate
> some of this pain, but until we get it in XenServer, we're somewhat stuck
> on flat networking.
>
> Paul
>
> On 2/3/11 4:20 AM, "Diego Parrilla Santamaría"
>  wrote:
>
>>Hi Monsyne,
>>
>>it's a very interesting topic and I'm curious about the reason why you
>>are using the Flat Networking set up. From the conversations in other
>>threads it seems the Service Providers prefer different networking
>>approaches: VLAN oriented basically.
>>
>>Regards
>>Diego
>>
>>-
>>Diego Parrilla
>>nubeblog.com | nubeb...@nubeblog.com | twitter.com/nubeblog
>>+34 649 94 43 29
>>
>>
>>
>>
>>On Thu, Feb 3, 2011 at 2:37 AM, Monsyne Dragon 
>>wrote:
>>> I am sorting out some possible implementations for the
>>> multi-tenant-accounting blueprint, and the related system-usage-records
>>>bp,
>>> and I just wanted to run this by anyone interested in such matters.
>>>
>>> Basically, for multitenant purposes we need to introduce the concept of
>>>an
>>> 'account' in nova, representing a customer,  that basically acts as a
>>>label
>>> for a group of resources (instances, etc), and for access control (i.e
>>> customer a cannot mess w/ customer b's stuff)
>>>
>>> There was some confusion on how best to implement this, in relation to
>>> nova's project concept.  Projects are kind of like what we want an
>>>account
>>> to be, but there are some associations (like one project per network)
>>>which
>>> are not valid for our flat networking setup.  I am kind of
>>>straw-polling on
>>> which is better here:
>>>
>>> The options are:
>>> 1) Create a new 'account' concept in nova,  with an account basically
>>>being
>>> a subgroup of a project (providers would use a single, default project,
>>>with
>>> additional projects added if needed for separate brands, or resellers,
>>>etc),
>>> add in access control per account as well as project, and make sure
>>> apis/auth specify account appropriately,  have some way for a default
>>> account to used (per project) so account doesn't get in the way for
>>> non-multitenant users.
>>>
>>> 2) having account == nova's "project", and changing the network
>>> associations, etc so projects can support our model (as well as current
>>> models).  Support for associating accounts (projects) together for
>>> resellers, etc would either be delegated outside of nova or added later
>>> (it's not a current requirement).
>>>
>>> In either case, accounts would be identified by name, which would  be an
>>> opaque string an outside system/person would assign, and could
>>>structure to
>>> their needs (ie. for associating accounts with common prefixes, etc)
>>>
>>> --
>>>
>>> --
>>>    -Monsyne Dragon
>>>    work:         210-312-4190
>>>    mobile        210-441-0965
>>>    google voice: 210-338-0336
>>>
>>>
>>>
>>> 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 ab...@rackspace.com, and delete the original message.
>>> Your cooperation is appreciated.
>>>
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to     : openstack@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help   : https://he

Re: [Openstack] Network Service for L2/L3 Network Infrastructure blueprint

[Ed Leafe]

On Feb 3, 2011, at 8:52 AM, Jay Pipes wrote:

>> Absolutely not, as long as we're not trying to merge conflicting branches.  
>> That was the problem last time -- I18N and the logging changes in particular 
>> were such pervasive pieces of work that it was hard work merging all the 
>> time.  Hopefully we won't see the likes of those again for a little while!
> 
> Hehe, understood. I did 6 or 7 merge trunks while dealing with i18n,
> so I feel you :)  But, luckily, we don't look to have any of those
> super-invasive blueprints on deck for Cactus...but you never know ;)


Is there any proscription about merging a partial change? IOW, if 
something like the logging change affected 100 files, would it be acceptable to 
merge, say, 20 at a time? As long as tests continue to pass, of course, and the 
merge prop is labeled as a partial implementation, and everything else 
continues to work without problem. This way any individual merge will only 
conflict with a few branches, while huge mega-merges will conflict with just 
about everything.


-- Ed Leafe




___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Network Service for L2/L3 Network Infrastructure blueprint

[Jay Pipes]

On Thu, Feb 3, 2011 at 8:46 AM, Ewan Mellor  wrote:
>> -Original Message-
>> From: Jay Pipes [mailto:jaypi...@gmail.com]
>> Sent: 03 February 2011 13:40
>> To: Armando Migliaccio
>> Cc: Ewan Mellor; Andy Smith; Rick Clark; Søren Hansen;
>> openstack@lists.launchpad.net
>> Subject: Re: [Openstack] Network Service for L2/L3 Network
>> Infrastructure blueprint
>>
>> On Thu, Feb 3, 2011 at 4:28 AM, Armando Migliaccio
>>  wrote:
>> > I second what Ewan said about the coding style in nova.virt.xenapi. I
>> was
>> > responsible for part of refactoring and I am no longer fond of it
>> either. I
>> > still think that it was good to break xenapi.py down as we did, but
>> with
>> > hindsight I would like to revise some of the choices made, and make
>> the code
>> > a bit more Pythonic.
>>
>> Nothing wrong with proposing for merging a branch that does
>> refactoring. It doesn't need to be tied to a bug or blueprint, but if
>> you wait until late in the Cactus cycle, it would have a smaller
>> chance of making it into Cactus since the priority is not refactoring
>> but instead stability and feature parity.
>>
>> So, nothing stopping anyone from proposing refactoring branches.  :)
>
> Absolutely not, as long as we're not trying to merge conflicting branches.  
> That was the problem last time -- I18N and the logging changes in particular 
> were such pervasive pieces of work that it was hard work merging all the 
> time.  Hopefully we won't see the likes of those again for a little while!

Hehe, understood. I did 6 or 7 merge trunks while dealing with i18n,
so I feel you :)  But, luckily, we don't look to have any of those
super-invasive blueprints on deck for Cactus...but you never know ;)

-jay

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Pondering multi-tenant needs in nova.

[Paul Voccio]

Diego,

Due to our networking topology, having a vlan per customer isn't really
feasible. Most switches are limited at 4k or 8k or even 32k. With more
customers than these switches can reasonably accommodate, having a single
vlan per customer either limits the portability within a cloud or limits
the scale at which you can build your cloud. Open vSwitch will alleviate
some of this pain, but until we get it in XenServer, we're somewhat stuck
on flat networking.

Paul

On 2/3/11 4:20 AM, "Diego Parrilla Santamaría"
 wrote:

>Hi Monsyne,
>
>it's a very interesting topic and I'm curious about the reason why you
>are using the Flat Networking set up. From the conversations in other
>threads it seems the Service Providers prefer different networking
>approaches: VLAN oriented basically.
>
>Regards
>Diego
>
>-
>Diego Parrilla
>nubeblog.com | nubeb...@nubeblog.com | twitter.com/nubeblog
>+34 649 94 43 29
>
>
>
>
>On Thu, Feb 3, 2011 at 2:37 AM, Monsyne Dragon 
>wrote:
>> I am sorting out some possible implementations for the
>> multi-tenant-accounting blueprint, and the related system-usage-records
>>bp,
>> and I just wanted to run this by anyone interested in such matters.
>>
>> Basically, for multitenant purposes we need to introduce the concept of
>>an
>> 'account' in nova, representing a customer,  that basically acts as a
>>label
>> for a group of resources (instances, etc), and for access control (i.e
>> customer a cannot mess w/ customer b's stuff)
>>
>> There was some confusion on how best to implement this, in relation to
>> nova's project concept.  Projects are kind of like what we want an
>>account
>> to be, but there are some associations (like one project per network)
>>which
>> are not valid for our flat networking setup.  I am kind of
>>straw-polling on
>> which is better here:
>>
>> The options are:
>> 1) Create a new 'account' concept in nova,  with an account basically
>>being
>> a subgroup of a project (providers would use a single, default project,
>>with
>> additional projects added if needed for separate brands, or resellers,
>>etc),
>> add in access control per account as well as project, and make sure
>> apis/auth specify account appropriately,  have some way for a default
>> account to used (per project) so account doesn't get in the way for
>> non-multitenant users.
>>
>> 2) having account == nova's "project", and changing the network
>> associations, etc so projects can support our model (as well as current
>> models).  Support for associating accounts (projects) together for
>> resellers, etc would either be delegated outside of nova or added later
>> (it's not a current requirement).
>>
>> In either case, accounts would be identified by name, which would  be an
>> opaque string an outside system/person would assign, and could
>>structure to
>> their needs (ie. for associating accounts with common prefixes, etc)
>>
>> --
>>
>> --
>>-Monsyne Dragon
>>work: 210-312-4190
>>mobile210-441-0965
>>google voice: 210-338-0336
>>
>>
>>
>> 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 ab...@rackspace.com, and delete the original message.
>> Your cooperation is appreciated.
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>>
>
>___
>Mailing list: https://launchpad.net/~openstack
>Post to : openstack@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 ab...@rackspace.com, and delete the original message. 
Your cooperation is appreciated.


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Network Service for L2/L3 Network Infrastructure blueprint

[Ewan Mellor]

> -Original Message-
> From: Jay Pipes [mailto:jaypi...@gmail.com]
> Sent: 03 February 2011 13:40
> To: Armando Migliaccio
> Cc: Ewan Mellor; Andy Smith; Rick Clark; Søren Hansen;
> openstack@lists.launchpad.net
> Subject: Re: [Openstack] Network Service for L2/L3 Network
> Infrastructure blueprint
> 
> On Thu, Feb 3, 2011 at 4:28 AM, Armando Migliaccio
>  wrote:
> > I second what Ewan said about the coding style in nova.virt.xenapi. I
> was
> > responsible for part of refactoring and I am no longer fond of it
> either. I
> > still think that it was good to break xenapi.py down as we did, but
> with
> > hindsight I would like to revise some of the choices made, and make
> the code
> > a bit more Pythonic.
> 
> Nothing wrong with proposing for merging a branch that does
> refactoring. It doesn't need to be tied to a bug or blueprint, but if
> you wait until late in the Cactus cycle, it would have a smaller
> chance of making it into Cactus since the priority is not refactoring
> but instead stability and feature parity.
> 
> So, nothing stopping anyone from proposing refactoring branches.  :)

Absolutely not, as long as we're not trying to merge conflicting branches.  
That was the problem last time -- I18N and the logging changes in particular 
were such pervasive pieces of work that it was hard work merging all the time.  
Hopefully we won't see the likes of those again for a little while!

Ewan.

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Pondering multi-tenant needs in nova.

[Jay Pipes]

2011/2/3 Diego Parrilla Santamaría :
> it's a very interesting topic and I'm curious about the reason why you
> are using the Flat Networking set up. From the conversations in other
> threads it seems the Service Providers prefer different networking
> approaches: VLAN oriented basically.

I don't think this is something that Monsyne has any control over ;)

May want to ask Rackspace networking engineers that question!

-jay

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Network Service for L2/L3 Network Infrastructure blueprint

[Jay Pipes]

On Thu, Feb 3, 2011 at 4:28 AM, Armando Migliaccio
 wrote:
> I second what Ewan said about the coding style in nova.virt.xenapi. I was
> responsible for part of refactoring and I am no longer fond of it either. I
> still think that it was good to break xenapi.py down as we did, but with
> hindsight I would like to revise some of the choices made, and make the code
> a bit more Pythonic.

Nothing wrong with proposing for merging a branch that does
refactoring. It doesn't need to be tied to a bug or blueprint, but if
you wait until late in the Cactus cycle, it would have a smaller
chance of making it into Cactus since the priority is not refactoring
but instead stability and feature parity.

So, nothing stopping anyone from proposing refactoring branches.  :)

-jay

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Pondering multi-tenant needs in nova.

[Diego Parrilla Santamaría]

Hi Monsyne,

it's a very interesting topic and I'm curious about the reason why you
are using the Flat Networking set up. From the conversations in other
threads it seems the Service Providers prefer different networking
approaches: VLAN oriented basically.

Regards
Diego

-
Diego Parrilla
nubeblog.com | nubeb...@nubeblog.com | twitter.com/nubeblog
+34 649 94 43 29




On Thu, Feb 3, 2011 at 2:37 AM, Monsyne Dragon  wrote:
> I am sorting out some possible implementations for the
> multi-tenant-accounting blueprint, and the related system-usage-records bp,
> and I just wanted to run this by anyone interested in such matters.
>
> Basically, for multitenant purposes we need to introduce the concept of an
> 'account' in nova, representing a customer,  that basically acts as a label
> for a group of resources (instances, etc), and for access control (i.e
> customer a cannot mess w/ customer b's stuff)
>
> There was some confusion on how best to implement this, in relation to
> nova's project concept.  Projects are kind of like what we want an account
> to be, but there are some associations (like one project per network) which
> are not valid for our flat networking setup.  I am kind of straw-polling on
> which is better here:
>
> The options are:
> 1) Create a new 'account' concept in nova,  with an account basically being
> a subgroup of a project (providers would use a single, default project, with
> additional projects added if needed for separate brands, or resellers, etc),
> add in access control per account as well as project, and make sure
> apis/auth specify account appropriately,  have some way for a default
> account to used (per project) so account doesn't get in the way for
> non-multitenant users.
>
> 2) having account == nova's "project", and changing the network
> associations, etc so projects can support our model (as well as current
> models).  Support for associating accounts (projects) together for
> resellers, etc would either be delegated outside of nova or added later
> (it's not a current requirement).
>
> In either case, accounts would be identified by name, which would  be an
> opaque string an outside system/person would assign, and could structure to
> their needs (ie. for associating accounts with common prefixes, etc)
>
> --
>
> --
>    -Monsyne Dragon
>    work:         210-312-4190
>    mobile        210-441-0965
>    google voice: 210-338-0336
>
>
>
> 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 ab...@rackspace.com, and delete the original message.
> Your cooperation is appreciated.
>
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] OpenStack "Bexar" release is out, packages for SLES and openSUSE are ready

[Stefan Seyfried]

On Thu, 03 Feb 2011 10:30:17 +0100
Thierry Carrez  wrote:

> Hello everyone,
> 
> It is my great pleasure to announce the direct availability of the
> second release of the OpenStack project, codenamed "Bexar".

For those that want to try OpenStack on openSUSE or SLES and are a bit
adventurous, there are now packages for both openSUSE 11.3 and SLES11SP1 at

  http://download.opensuse.org/repositories/isv:/B1-Systems:/OpenStack/

courtesy of B1 Systems and the openSUSE Build Service :-)

Everything needed should be in those repos, if something is missing,
please let me know. A big "Thank You" goes to Christian Behrendt and Andre
Naehring, who have been tireless beta testers of my packaging tries.

Have a lot of fun...

Stefan
-- 
Stefan Seyfried
Linux Consultant & Developer
Mail: seyfr...@b1-systems.de GPG Key: 0x731B665B

B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] OpenStack "Bexar" release is out

[Thierry Carrez]

Hello everyone,

It is my great pleasure to announce the direct availability of the
second release of the OpenStack project, codenamed "Bexar".

The release consists of the following deliverables:

Swift 1.2.0: https://launchpad.net/swift/1.2/1.2.0
Nova 2011.1: https://launchpad.net/nova/bexar/2011.1
Glance 0.1.7: https://launchpad.net/glance/bexar/0.1.7

Please see the release notes for details on new features or known issues
in this release:

http://wiki.openstack.org/ReleaseNotes/Bexar

Congrats to the team, looking forward to working with you all on the
next release, codenamed "Cactus".

-- 
Thierry Carrez (ttx)
Release Manager, OpenStack

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Network Service for L2/L3 Network Infrastructure blueprint

[Armando Migliaccio]

I second what Ewan said about the coding style in nova.virt.xenapi. I was 
responsible for part of refactoring and I am no longer fond of it either. I 
still think that it was good to break xenapi.py down as we did, but with 
hindsight I would like to revise some of the choices made, and make the code a 
bit more Pythonic.

Armando

From: openstack-bounces+armando.migliaccio=eu.citrix@lists.launchpad.net 
[mailto:openstack-bounces+armando.migliaccio=eu.citrix@lists.launchpad.net] 
On Behalf Of Ewan Mellor
Sent: 02 February 2011 22:08
To: Andy Smith; Rick Clark
Cc: Søren Hansen; openstack@lists.launchpad.net
Subject: Re: [Openstack] Network Service for L2/L3 Network Infrastructure 
blueprint

> Try as we might there is still not a real consensus on high level coding 
> style, for example the Xen-related code is radically different in shape and 
> style from
> the libvirt code as is the rackspace api from the ec2 api, and having 
> projects split off only worsens the problem as individual developers have 
> fewer eyes on them.

For what it’s worth, I’m not entirely happy with the coding style in 
nova.virt.xenapi either, so we might not be as far from consensus as you think. 
 Some of the “Java-ish” code was allowed through code review for the sake of 
expedience, because it was a big improvement over what was there, even if it 
wasn’t perfect.  I’d like to rework this whenever there’s a sensible time to do 
so.

Also, I’d love for us to be using the same code paths as much as possible, and 
whatever help you need getting off KVM and onto a proper hypervisor, I’m more 
than happy to help ;-)

Ewan.

From: Andy Smith [mailto:andys...@gmail.com]
Sent: 28 January 2011 15:40
To: Rick Clark
Cc: Jay Pipes; Ewan Mellor; Søren Hansen; openstack@lists.launchpad.net
Subject: Re: [Openstack] Network Service for L2/L3 Network Infrastructure 
blueprint

I'd second a bit of what Jay says and toss in that I don't think the code is 
ready to be splitting services off:

- There have already been significant problems dealing with glance, the nasa 
people and the rackspace people have effectively completely different code 
paths (nasa: ec2, objectstore, libvirt; rackspace: rackspace, glance, xenapi) 
and that needs to be aligned a bit more before we can create more separations 
if we want everybody to be working towards the same goals.
- Try as we might there is still not a real consensus on high level coding 
style, for example the Xen-related code is radically different in shape and 
style from the libvirt code as is the rackspace api from the ec2 api, and 
having projects split off only worsens the problem as individual developers 
have fewer eyes on them.

My goal and as far as I can tell most of my team's goals are to rectify a lot 
of that situation over the course of the next release by:

- setting up and working through the rackspace side of the code paths (as 
mentioned above) enough that we can start generalizing its utility for the 
entire project
- actual deprecation of the majority of objectstore
- more thorough code reviews to ensure that code is meeting the overall style 
of the project, and probably a document describing the code review process

After Cactus if the idea makes sense to split off then it can be pursued then, 
but at the moment it is much too early to consider it.

On Fri, Jan 28, 2011 at 7:06 AM, Rick Clark 
mailto:r...@openstack.org>> wrote:
On 01/28/2011 08:55 AM, Jay Pipes wrote:
> On Fri, Jan 28, 2011 at 8:47 AM, Rick Clark 
> mailto:r...@openstack.org>> wrote:
> I recognise the desire to do this for Cactus, but I feel that pulling
> out the network controller (and/or volume controller) into their own
> separate OpenStack subprojects is not a good idea for Cactus.  Looking
> at the (dozens of) blueprints slated for Cactus, doing this kind of
> major rework will mean that most (if not all) of those blueprints will
> have to be delayed while this pulling out of code occurs. This will
> definitely jeopardise the Cactus release.
>
> My vote is to delay this at a minimum to the Diablo release.
>
> And, for the record, I haven't seen any blueprints for the network as
> a service or volume as a service projects. Can someone point us to
> them?
>
> Thanks!
> jay
Whew, Jay I thought you were advocating major changes in Cactus.  That
would completely mess up my view of the world :)

https://blueprints.launchpad.net/nova/+spec/bexar-network-service
https://blueprints.launchpad.net/nova/+spec/bexar-extend-network-model
https://blueprints.launchpad.net/nova/+spec/bexar-network-service


It was discussed at ODS, but I have not seen any code or momentum, to date.

I think it is worth while to have an open discussion about what if any
of this can be safely done in Cactus.  I like you, Jay, feel a bit
conservative.  I think we lost focus of the reason we chose time based
releases. It is time to focus on nova being a solid trustworthy
platform.  Features land when they are of sufficient quality, releas