Re: [openstack-dev] [keystone] role of Domain in VPC definition

2014-02-16 Thread Joe Gordon
On Sun, Feb 16, 2014 at 3:26 AM, Salvatore Orlando  wrote:
> It seems this work item is made of several blueprints, some of which are not
> yet approved. This is true at least for the Neutron blueprint regarding
> policy extensions.
>
> Since I first looked at this spec I've been wondering why nova has been
> selected as an endpoint for network operations rather than Neutron, but this
> probably a design/implementation details whereas JC here is looking at the
> general approach.

[1] is only about AWS VPC support, not OpenStack API based network operations.

>
> Nevertheless, my only point here is that is seems that features like this
> need an "all-or-none" approval.
> For instance, could the VPC feature be considered functional if blueprint
> [1] is implemented, but not [2] and [3]?
>
> Salvatore
>
> [1] https://blueprints.launchpad.net/nova/+spec/aws-vpc-support
> [2]
> https://blueprints.launchpad.net/neutron/+spec/policy-extensions-for-neutron
> [3]
> https://blueprints.launchpad.net/keystone/+spec/hierarchical-multitenancy
>
>
> On 11 February 2014 21:45, Martin, JC  wrote:
>>
>> Ravi,
>>
>> It seems that the following Blueprint
>> https://wiki.openstack.org/wiki/Blueprint-aws-vpc-support
>>
>> has been approved.
>>
>> However, I cannot find a discussion with regard to the merit of using
>> project vs. domain, or other mechanism for the implementation.
>>
>> I have an issue with this approach as it prevents tenants within the same
>> domain sharing the same VPC to have projects.
>>
>> As an example, if you are a large organization on AWS, it is likely that
>> you have a large VPC that will be shred by multiple projects. With this
>> proposal, we loose that capability, unless I missed something.
>>
>> JC
>>
>> On Dec 19, 2013, at 6:10 PM, Ravi Chunduru  wrote:
>>
>> > Hi,
>> >   We had some internal discussions on role of Domain and VPCs. I would
>> > like to expand and understand community thinking of Keystone domain and
>> > VPCs.
>> >
>> > Is VPC equivalent to Keystone Domain?
>> >
>> > If so, as a public cloud provider - I create a Keystone domain and give
>> > it to an organization which wants a virtual private cloud.
>> >
>> > Now the question is if that organization wants to have  departments wise
>> > allocation of resources it is becoming difficult to visualize with existing
>> > v3 keystone constructs.
>> >
>> > Currently, it looks like each department of an organization cannot have
>> > their own resource management with in the organization VPC ( LDAP based 
>> > user
>> > management, network management or dedicating computes etc.,) For us,
>> > Openstack Project does not match the requirements of a department of an
>> > organization.
>> >
>> > I hope you guessed what we wanted - Domain must have VPCs and VPC to
>> > have projects.
>> >
>> > I would like to know how community see the VPC model in Openstack.
>> >
>> > Thanks,
>> > -Ravi.
>> >
>> >
>> > ___
>> > OpenStack-dev mailing list
>> > OpenStack-dev@lists.openstack.org
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [keystone] role of Domain in VPC definition

2014-02-16 Thread Ravi Chunduru
I agree with JC that we need to pause and discuss VPC model with in
openstack before considering AWS compatibility. As Subbu said, We need this
discussion in Juno summit and get consensus.

Thanks,
-Ravi.


On Sun, Feb 16, 2014 at 10:31 AM, Allamaraju, Subbu  wrote:

> Harshad,
>
> This is great. At least there is consensus on what it is and what it is
> not. I would leave it to others to discuss merits of a an AWS compat VPC
> API for Icehouse.
>
> Perhaps this is a good topic to discuss at the Juno design summit.
>
> Subbu
>
> On Feb 16, 2014, at 10:15 AM, Harshad Nakil 
> wrote:
>
> > As said I am not disagreeing with you or Ravi or JC. I also agree that
> > Openstack VPC implementation will benefit from these proposals.
> > What I am saying is it is not required AWS VPC API compatibility at
> > this point.  Which is what our blueprint is all about. We are not
> > defining THE "VPC".
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Ravi
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [keystone] role of Domain in VPC definition

2014-02-16 Thread Allamaraju, Subbu
Harshad,

This is great. At least there is consensus on what it is and what it is not. I 
would leave it to others to discuss merits of a an AWS compat VPC API for 
Icehouse.

Perhaps this is a good topic to discuss at the Juno design summit.

Subbu

On Feb 16, 2014, at 10:15 AM, Harshad Nakil  wrote:

> As said I am not disagreeing with you or Ravi or JC. I also agree that
> Openstack VPC implementation will benefit from these proposals.
> What I am saying is it is not required AWS VPC API compatibility at
> this point.  Which is what our blueprint is all about. We are not
> defining THE "VPC".


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [keystone] role of Domain in VPC definition

2014-02-16 Thread Harshad Nakil
As said I am not disagreeing with you or Ravi or JC. I also agree that
Openstack VPC implementation will benefit from these proposals.
What I am saying is it is not required AWS VPC API compatibility at
this point.  Which is what our blueprint is all about. We are not
defining THE "VPC".
Let me ask you what changes in AWS API when you go to other model?
The argument is you want multiple projects in VPC. That's great. But I
don't understand how I would specify it if my code was written to use
AWS API.
The argument you want multiple external networks per VPC I don't know
how to specify using AWS API
So list goes on.

May be I am missing something. If you don't want AWS compatibility
then that's different issue all together. And should be discussed as
such.

Regards
-Harshad


> On Feb 16, 2014, at 9:51 AM, "Allamaraju, Subbu"  wrote:
>
> Harshad,
>
> But the key question that Ravi brought up remains though. A project is a very 
> small administrative container to manage policies and resources for VPCs. 
> We've been experimenting with VPCs on OpenStack (with some mods) at work for 
> nearly a year, and came across cases where hundreds/thousands of apps in 
> equal number of projects needing to share resources and policies, and project 
> to VPC mapping did not cut.
>
> I was wondering if there was prior discussion around the mapping of AWS VPC 
> model to OpenStack concepts like projects and domains. Thanks for any 
> pointers.
>
> Subbu
>
>> On Feb 16, 2014, at 8:01 AM, Harshad Nakil  
>> wrote:
>>
>> Yes, [1] can be done without [2] and [3].
>> As you are well aware [2] is now merged with group policy discussions.
>> IMHO all or nothing approach will not get us anywhere.
>> By the time we line up all our ducks in row. New features/ideas/blueprints 
>> will keep Emerging.
>>
>> Regards
>> -Harshad
>>
>>
>>> On Feb 16, 2014, at 2:30 AM, Salvatore Orlando  wrote:
>>>
>>> It seems this work item is made of several blueprints, some of which are 
>>> not yet approved. This is true at least for the Neutron blueprint regarding 
>>> policy extensions.
>>>
>>> Since I first looked at this spec I've been wondering why nova has been 
>>> selected as an endpoint for network operations rather than Neutron, but 
>>> this probably a design/implementation details whereas JC here is looking at 
>>> the general approach.
>>>
>>> Nevertheless, my only point here is that is seems that features like this 
>>> need an "all-or-none" approval.
>>> For instance, could the VPC feature be considered functional if blueprint 
>>> [1] is implemented, but not [2] and [3]?
>>>
>>> Salvatore
>>>
>>> [1] https://blueprints.launchpad.net/nova/+spec/aws-vpc-support
>>> [2] 
>>> https://blueprints.launchpad.net/neutron/+spec/policy-extensions-for-neutron
>>> [3] 
>>> https://blueprints.launchpad.net/keystone/+spec/hierarchical-multitenancy
>>>
>>>
>>> On 11 February 2014 21:45, Martin, JC  wrote:
>>> Ravi,
>>>
>>> It seems that the following Blueprint
>>> https://wiki.openstack.org/wiki/Blueprint-aws-vpc-support
>>>
>>> has been approved.
>>>
>>> However, I cannot find a discussion with regard to the merit of using 
>>> project vs. domain, or other mechanism for the implementation.
>>>
>>> I have an issue with this approach as it prevents tenants within the same 
>>> domain sharing the same VPC to have projects.
>>>
>>> As an example, if you are a large organization on AWS, it is likely that 
>>> you have a large VPC that will be shred by multiple projects. With this 
>>> proposal, we loose that capability, unless I missed something.
>>>
>>> JC
>>>
 On Dec 19, 2013, at 6:10 PM, Ravi Chunduru  wrote:

 Hi,
  We had some internal discussions on role of Domain and VPCs. I would like 
 to expand and understand community thinking of Keystone domain and VPCs.

 Is VPC equivalent to Keystone Domain?

 If so, as a public cloud provider - I create a Keystone domain and give it 
 to an organization which wants a virtual private cloud.

 Now the question is if that organization wants to have  departments wise 
 allocation of resources it is becoming difficult to visualize with 
 existing v3 keystone constructs.

 Currently, it looks like each department of an organization cannot have 
 their own resource management with in the organization VPC ( LDAP based 
 user management, network management or dedicating computes etc.,) For us, 
 Openstack Project does not match the requirements of a department of an 
 organization.

 I hope you guessed what we wanted - Domain must have VPCs and VPC to have 
 projects.

 I would like to know how community see the VPC model in Openstack.

 Thanks,
 -Ravi.


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>> _

Re: [openstack-dev] [keystone] role of Domain in VPC definition

2014-02-16 Thread Allamaraju, Subbu
Harshad,

But the key question that Ravi brought up remains though. A project is a very 
small administrative container to manage policies and resources for VPCs. We've 
been experimenting with VPCs on OpenStack (with some mods) at work for nearly a 
year, and came across cases where hundreds/thousands of apps in equal number of 
projects needing to share resources and policies, and project to VPC mapping 
did not cut. 

I was wondering if there was prior discussion around the mapping of AWS VPC 
model to OpenStack concepts like projects and domains. Thanks for any pointers.

Subbu

On Feb 16, 2014, at 8:01 AM, Harshad Nakil  wrote:

> Yes, [1] can be done without [2] and [3]. 
> As you are well aware [2] is now merged with group policy discussions. 
> IMHO all or nothing approach will not get us anywhere. 
> By the time we line up all our ducks in row. New features/ideas/blueprints 
> will keep Emerging.  
> 
> Regards
> -Harshad
> 
> 
> On Feb 16, 2014, at 2:30 AM, Salvatore Orlando  wrote:
> 
>> It seems this work item is made of several blueprints, some of which are not 
>> yet approved. This is true at least for the Neutron blueprint regarding 
>> policy extensions.
>> 
>> Since I first looked at this spec I've been wondering why nova has been 
>> selected as an endpoint for network operations rather than Neutron, but this 
>> probably a design/implementation details whereas JC here is looking at the 
>> general approach.
>> 
>> Nevertheless, my only point here is that is seems that features like this 
>> need an "all-or-none" approval.
>> For instance, could the VPC feature be considered functional if blueprint 
>> [1] is implemented, but not [2] and [3]?
>> 
>> Salvatore
>> 
>> [1] https://blueprints.launchpad.net/nova/+spec/aws-vpc-support
>> [2] 
>> https://blueprints.launchpad.net/neutron/+spec/policy-extensions-for-neutron
>> [3] https://blueprints.launchpad.net/keystone/+spec/hierarchical-multitenancy
>> 
>> 
>> On 11 February 2014 21:45, Martin, JC  wrote:
>> Ravi,
>> 
>> It seems that the following Blueprint
>> https://wiki.openstack.org/wiki/Blueprint-aws-vpc-support
>> 
>> has been approved.
>> 
>> However, I cannot find a discussion with regard to the merit of using 
>> project vs. domain, or other mechanism for the implementation.
>> 
>> I have an issue with this approach as it prevents tenants within the same 
>> domain sharing the same VPC to have projects.
>> 
>> As an example, if you are a large organization on AWS, it is likely that you 
>> have a large VPC that will be shred by multiple projects. With this 
>> proposal, we loose that capability, unless I missed something.
>> 
>> JC
>> 
>> On Dec 19, 2013, at 6:10 PM, Ravi Chunduru  wrote:
>> 
>> > Hi,
>> >   We had some internal discussions on role of Domain and VPCs. I would 
>> > like to expand and understand community thinking of Keystone domain and 
>> > VPCs.
>> >
>> > Is VPC equivalent to Keystone Domain?
>> >
>> > If so, as a public cloud provider - I create a Keystone domain and give it 
>> > to an organization which wants a virtual private cloud.
>> >
>> > Now the question is if that organization wants to have  departments wise 
>> > allocation of resources it is becoming difficult to visualize with 
>> > existing v3 keystone constructs.
>> >
>> > Currently, it looks like each department of an organization cannot have 
>> > their own resource management with in the organization VPC ( LDAP based 
>> > user management, network management or dedicating computes etc.,) For us, 
>> > Openstack Project does not match the requirements of a department of an 
>> > organization.
>> >
>> > I hope you guessed what we wanted - Domain must have VPCs and VPC to have 
>> > projects.
>> >
>> > I would like to know how community see the VPC model in Openstack.
>> >
>> > Thanks,
>> > -Ravi.
>> >
>> >
>> > ___
>> > OpenStack-dev mailing list
>> > OpenStack-dev@lists.openstack.org
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>> 
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [keystone] role of Domain in VPC definition

2014-02-16 Thread Harshad Nakil
Yes, [1] can be done without [2] and [3].
As you are well aware [2] is now merged with group policy discussions.
IMHO all or nothing approach will not get us anywhere.
By the time we line up all our ducks in row. New features/ideas/blueprints
will keep Emerging.

Regards
-Harshad


On Feb 16, 2014, at 2:30 AM, Salvatore Orlando  wrote:

It seems this work item is made of several blueprints, some of which are
not yet approved. This is true at least for the Neutron blueprint regarding
policy extensions.

Since I first looked at this spec I've been wondering why nova has been
selected as an endpoint for network operations rather than Neutron, but
this probably a design/implementation details whereas JC here is looking at
the general approach.

Nevertheless, my only point here is that is seems that features like this
need an "all-or-none" approval.
For instance, could the VPC feature be considered functional if blueprint
[1] is implemented, but not [2] and [3]?

Salvatore

[1] https://blueprints.launchpad.net/nova/+spec/aws-vpc-support
[2]
https://blueprints.launchpad.net/neutron/+spec/policy-extensions-for-neutron
[3]
https://blueprints.launchpad.net/keystone/+spec/hierarchical-multitenancy


On 11 February 2014 21:45, Martin, JC  wrote:

> Ravi,
>
> It seems that the following Blueprint
> https://wiki.openstack.org/wiki/Blueprint-aws-vpc-support
>
> has been approved.
>
> However, I cannot find a discussion with regard to the merit of using
> project vs. domain, or other mechanism for the implementation.
>
> I have an issue with this approach as it prevents tenants within the same
> domain sharing the same VPC to have projects.
>
> As an example, if you are a large organization on AWS, it is likely that
> you have a large VPC that will be shred by multiple projects. With this
> proposal, we loose that capability, unless I missed something.
>
> JC
>
> On Dec 19, 2013, at 6:10 PM, Ravi Chunduru  wrote:
>
> > Hi,
> >   We had some internal discussions on role of Domain and VPCs. I would
> like to expand and understand community thinking of Keystone domain and
> VPCs.
> >
> > Is VPC equivalent to Keystone Domain?
> >
> > If so, as a public cloud provider - I create a Keystone domain and give
> it to an organization which wants a virtual private cloud.
> >
> > Now the question is if that organization wants to have  departments wise
> allocation of resources it is becoming difficult to visualize with existing
> v3 keystone constructs.
> >
> > Currently, it looks like each department of an organization cannot have
> their own resource management with in the organization VPC ( LDAP based
> user management, network management or dedicating computes etc.,) For us,
> Openstack Project does not match the requirements of a department of an
> organization.
> >
> > I hope you guessed what we wanted - Domain must have VPCs and VPC to
> have projects.
> >
> > I would like to know how community see the VPC model in Openstack.
> >
> > Thanks,
> > -Ravi.
> >
> >
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [keystone] role of Domain in VPC definition

2014-02-16 Thread Salvatore Orlando
It seems this work item is made of several blueprints, some of which are
not yet approved. This is true at least for the Neutron blueprint regarding
policy extensions.

Since I first looked at this spec I've been wondering why nova has been
selected as an endpoint for network operations rather than Neutron, but
this probably a design/implementation details whereas JC here is looking at
the general approach.

Nevertheless, my only point here is that is seems that features like this
need an "all-or-none" approval.
For instance, could the VPC feature be considered functional if blueprint
[1] is implemented, but not [2] and [3]?

Salvatore

[1] https://blueprints.launchpad.net/nova/+spec/aws-vpc-support
[2]
https://blueprints.launchpad.net/neutron/+spec/policy-extensions-for-neutron
[3]
https://blueprints.launchpad.net/keystone/+spec/hierarchical-multitenancy


On 11 February 2014 21:45, Martin, JC  wrote:

> Ravi,
>
> It seems that the following Blueprint
> https://wiki.openstack.org/wiki/Blueprint-aws-vpc-support
>
> has been approved.
>
> However, I cannot find a discussion with regard to the merit of using
> project vs. domain, or other mechanism for the implementation.
>
> I have an issue with this approach as it prevents tenants within the same
> domain sharing the same VPC to have projects.
>
> As an example, if you are a large organization on AWS, it is likely that
> you have a large VPC that will be shred by multiple projects. With this
> proposal, we loose that capability, unless I missed something.
>
> JC
>
> On Dec 19, 2013, at 6:10 PM, Ravi Chunduru  wrote:
>
> > Hi,
> >   We had some internal discussions on role of Domain and VPCs. I would
> like to expand and understand community thinking of Keystone domain and
> VPCs.
> >
> > Is VPC equivalent to Keystone Domain?
> >
> > If so, as a public cloud provider - I create a Keystone domain and give
> it to an organization which wants a virtual private cloud.
> >
> > Now the question is if that organization wants to have  departments wise
> allocation of resources it is becoming difficult to visualize with existing
> v3 keystone constructs.
> >
> > Currently, it looks like each department of an organization cannot have
> their own resource management with in the organization VPC ( LDAP based
> user management, network management or dedicating computes etc.,) For us,
> Openstack Project does not match the requirements of a department of an
> organization.
> >
> > I hope you guessed what we wanted - Domain must have VPCs and VPC to
> have projects.
> >
> > I would like to know how community see the VPC model in Openstack.
> >
> > Thanks,
> > -Ravi.
> >
> >
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [keystone] role of Domain in VPC definition

2014-02-11 Thread Martin, JC
Ravi,

It seems that the following Blueprint 
https://wiki.openstack.org/wiki/Blueprint-aws-vpc-support

has been approved. 

However, I cannot find a discussion with regard to the merit of using project 
vs. domain, or other mechanism for the implementation.

I have an issue with this approach as it prevents tenants within the same 
domain sharing the same VPC to have projects.

As an example, if you are a large organization on AWS, it is likely that you 
have a large VPC that will be shred by multiple projects. With this proposal, 
we loose that capability, unless I missed something.

JC

On Dec 19, 2013, at 6:10 PM, Ravi Chunduru  wrote:

> Hi,
>   We had some internal discussions on role of Domain and VPCs. I would like 
> to expand and understand community thinking of Keystone domain and VPCs.
> 
> Is VPC equivalent to Keystone Domain?
> 
> If so, as a public cloud provider - I create a Keystone domain and give it to 
> an organization which wants a virtual private cloud.
> 
> Now the question is if that organization wants to have  departments wise 
> allocation of resources it is becoming difficult to visualize with existing 
> v3 keystone constructs.
> 
> Currently, it looks like each department of an organization cannot have their 
> own resource management with in the organization VPC ( LDAP based user 
> management, network management or dedicating computes etc.,) For us, 
> Openstack Project does not match the requirements of a department of an 
> organization.
> 
> I hope you guessed what we wanted - Domain must have VPCs and VPC to have 
> projects.
> 
> I would like to know how community see the VPC model in Openstack.
> 
> Thanks,
> -Ravi.
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev