Re: [openstack-dev] VPC Proposal

[Rudra Rugge]

JC,

We have a complete implementation which I had submitted earlier. But since the 
code was too large the community decided to move forward in a phased approach. 
The plan is to provide close to complete compatibility in a multi-phase manner 
as mentioned in the blueprint. Phase 4 (internet gateway, VPN, NAT etc)  was 
not added to the blueprint as that was dependent on VPNaas, FWaaS, NATaas.

Comments inline:


On Feb 19, 2014, at 9:05 AM, Martin, JC 
mailto:jch.mar...@gmail.com>> wrote:

Comments in line.

JC
On Feb 18, 2014, at 5:21 PM, Rudra Rugge 
mailto:rru...@juniper.net>> wrote:

Please see inline:

On Feb 18, 2014, at 2:57 PM, Martin, JC 
mailto:jch.mar...@gmail.com>> wrote:

Maybe I should explain this one a bit.

Shared network: If a user has defined a shared network, and they used your API 
to create a VPC, the instances within the VPC will automatically get an 
interface on the shared network. I don't think that this is the expected 
behavior


When a user launches a VM in a VPC (AWS) the user needs to specify a subnet 
(network in openstack terminology) for each of the interfaces. Hence the 
instances will only get interfaces on the passed subnets/networks. The network 
being shared or not is not relevant for the VM launch. AWS APIs need the 
subnet/network to be passed for a VM launch in VPC.

Thanks, this makes sense.



FIP in scope of VPC: I was not talking about the EIP for Internet access, sorry 
if it was confusing. Since you are not really describing how you create the 
external networks, it's not clear how you implement the multiple gateways 
(public and private) that AWS supports, and how you connects networks to 
routers and external networks. i.e. are the CIDRs used in the VPC, NAT'ED to be 
routed in the customer datacenter, in which case, there is a floating IP pool 
that is private to each private gateway and VPC (not the 'public' one).

Gateways are built using Openstack neutron router resource. Networks are 
connected to the router interfaces. For internet access cloud administrator 
needs to provision a floating IP pool for the router to use. For CIDRs used in 
the VPC we need to implement a route-table extension which holds the prefix 
list. The prefix-list or route-table is attached to a 
subnet(AWS)/network(Openstack).  All internal(private) routing is managed by 
the Openstack router. NAT and VPN are used as next-hops to exit the VPC. In 
these cases similar to AWS we need to launch NAT and VPN capable instances as 
supported by Openstack FWAAS and VPNAAS.

I looked in the code referenced but did not find any router attachment call. 
Did I miss something ?
Also, what about these calls: CreateInternetGateway, AttachInternetGateway, 
CreateCustomerGateway, … don't you need that define how the VPC attach outside ?

[Rudra] We are going with a phased approach as I noted above. The code 
submitted is only for phase 1 of the blueprint.


What about mapping the optional attributes too (e.g. InstanceTenancy) ? What's 
the point of providing only partial compatibility ?

[Rudra] As mentioned above there is full compatibility available but we need to 
handle this in multiple phases.


Rudra




It would be useful for you to describe the pre-setup required to do make this 
works.

The only pre-setup needed by the cloud admin is to provide a public pool for 
floating IP.

Rudra



JC


On Feb 18, 2014, at 1:09 PM, Harshad Nakil 
mailto:hna...@contrailsystems.com>> wrote:

2. It does give full AWS compatibility (except for network ACL which was 
differed). Shared networks, FIP within scope of VPC is not some thing AWS 
provides. So it is not partial support.


___
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] VPC Proposal

[Martin, JC]

Comments in line.

JC
On Feb 18, 2014, at 5:21 PM, Rudra Rugge  wrote:

> Please see inline:
> 
> On Feb 18, 2014, at 2:57 PM, Martin, JC  wrote:
> 
>> Maybe I should explain this one a bit.
>> 
>> Shared network: If a user has defined a shared network, and they used your 
>> API to create a VPC, the instances within the VPC will automatically get an 
>> interface on the shared network. I don't think that this is the expected 
>> behavior
>> 
> 
> When a user launches a VM in a VPC (AWS) the user needs to specify a subnet 
> (network in openstack terminology) for each of the interfaces. Hence the 
> instances will only get interfaces on the passed subnets/networks. The 
> network being shared or not is not relevant for the VM launch. AWS APIs need 
> the subnet/network to be passed for a VM launch in VPC.

Thanks, this makes sense. 

> 
> 
>> FIP in scope of VPC: I was not talking about the EIP for Internet access, 
>> sorry if it was confusing. Since you are not really describing how you 
>> create the external networks, it's not clear how you implement the multiple 
>> gateways (public and private) that AWS supports, and how you connects 
>> networks to routers and external networks. i.e. are the CIDRs used in the 
>> VPC, NAT'ED to be routed in the customer datacenter, in which case, there is 
>> a floating IP pool that is private to each private gateway and VPC (not the 
>> 'public' one).
> 
> Gateways are built using Openstack neutron router resource. Networks are 
> connected to the router interfaces. For internet access cloud administrator 
> needs to provision a floating IP pool for the router to use. For CIDRs used 
> in the VPC we need to implement a route-table extension which holds the 
> prefix list. The prefix-list or route-table is attached to a 
> subnet(AWS)/network(Openstack).  All internal(private) routing is managed by 
> the Openstack router. NAT and VPN are used as next-hops to exit the VPC. In 
> these cases similar to AWS we need to launch NAT and VPN capable instances as 
> supported by Openstack FWAAS and VPNAAS. 

I looked in the code referenced but did not find any router attachment call. 
Did I miss something ? 
Also, what about these calls: CreateInternetGateway, AttachInternetGateway, 
CreateCustomerGateway, … don't you need that define how the VPC attach outside ?

What about mapping the optional attributes too (e.g. InstanceTenancy) ? What's 
the point of providing only partial compatibility ?

> 
>> 
>> It would be useful for you to describe the pre-setup required to do make 
>> this works.
> 
> The only pre-setup needed by the cloud admin is to provide a public pool for 
> floating IP. 
> 
> Rudra
> 
>> 
>> 
>> JC
>> 
>> 
>> On Feb 18, 2014, at 1:09 PM, Harshad Nakil  
>> wrote:
>> 
>>> 2. It does give full AWS compatibility (except for network ACL which was 
>>> differed). Shared networks, FIP within scope of VPC is not some thing AWS 
>>> provides. So it is not partial support.
>> 
>> 
>> ___
>> 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] VPC Proposal

[Rudra Rugge]

Please see inline:

On Feb 18, 2014, at 2:57 PM, Martin, JC  wrote:

> Maybe I should explain this one a bit.
> 
> Shared network: If a user has defined a shared network, and they used your 
> API to create a VPC, the instances within the VPC will automatically get an 
> interface on the shared network. I don't think that this is the expected 
> behavior
> 

When a user launches a VM in a VPC (AWS) the user needs to specify a subnet 
(network in openstack terminology) for each of the interfaces. Hence the 
instances will only get interfaces on the passed subnets/networks. The network 
being shared or not is not relevant for the VM launch. AWS APIs need the 
subnet/network to be passed for a VM launch in VPC.


> FIP in scope of VPC: I was not talking about the EIP for Internet access, 
> sorry if it was confusing. Since you are not really describing how you create 
> the external networks, it's not clear how you implement the multiple gateways 
> (public and private) that AWS supports, and how you connects networks to 
> routers and external networks. i.e. are the CIDRs used in the VPC, NAT'ED to 
> be routed in the customer datacenter, in which case, there is a floating IP 
> pool that is private to each private gateway and VPC (not the 'public' one).

Gateways are built using Openstack neutron router resource. Networks are 
connected to the router interfaces. For internet access cloud administrator 
needs to provision a floating IP pool for the router to use. For CIDRs used in 
the VPC we need to implement a route-table extension which holds the prefix 
list. The prefix-list or route-table is attached to a 
subnet(AWS)/network(Openstack).  All internal(private) routing is managed by 
the Openstack router. NAT and VPN are used as next-hops to exit the VPC. In 
these cases similar to AWS we need to launch NAT and VPN capable instances as 
supported by Openstack FWAAS and VPNAAS. 

> 
> It would be useful for you to describe the pre-setup required to do make this 
> works.

The only pre-setup needed by the cloud admin is to provide a public pool for 
floating IP. 

Rudra

> 
> 
> JC
> 
> 
> On Feb 18, 2014, at 1:09 PM, Harshad Nakil  wrote:
> 
>> 2. It does give full AWS compatibility (except for network ACL which was 
>> differed). Shared networks, FIP within scope of VPC is not some thing AWS 
>> provides. So it is not partial support.
> 
> 
> ___
> 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] VPC Proposal

[Martin, JC]

Maybe I should explain this one a bit.

Shared network: If a user has defined a shared network, and they used your API 
to create a VPC, the instances within the VPC will automatically get an 
interface on the shared network. I don't think that this is the expected 
behavior

FIP in scope of VPC: I was not talking about the EIP for Internet access, sorry 
if it was confusing. Since you are not really describing how you create the 
external networks, it's not clear how you implement the multiple gateways 
(public and private) that AWS supports, and how you connects networks to 
routers and external networks. i.e. are the CIDRs used in the VPC, NAT'ED to be 
routed in the customer datacenter, in which case, there is a floating IP pool 
that is private to each private gateway and VPC (not the 'public' one).

It would be useful for you to describe the pre-setup required to do make this 
works.


JC


On Feb 18, 2014, at 1:09 PM, Harshad Nakil  wrote:

> 2. It does give full AWS compatibility (except for network ACL which was 
> differed). Shared networks, FIP within scope of VPC is not some thing AWS 
> provides. So it is not partial support.


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

Re: [openstack-dev] VPC Proposal

[Joe Gordon]

On Tue, Feb 18, 2014 at 1:01 PM, Martin, JC  wrote:
> Joe,
>
> See my comments in line.
>
> On Feb 18, 2014, at 12:26 PM, Joe Gordon  wrote:
>
>> On Tue, Feb 18, 2014 at 10:03 AM, Martin, JC  wrote:
>>> There was a lot of emails on that thread, but I am not seeing the 
>>> discussion converging. I would like to reiterate my concerns:
>>>
>>>   - We are trying to implement an API on a feature that is not supported by 
>>> openstack
>>
>> I don't see it that way. I see this BP as converting neutron calls
>> into AWS VPC calls with a little glue (which can be seen here
>> https://wiki.openstack.org/wiki/Blueprint-aws-vpc-support). But I am
>> no networking expert, so take that with a large grain of salt.
>
> If we had the supporting constructs, I would be in favor of implementing the 
> AWS VPC features.
>
>>
>>>   - As a result, the implementation is overloading existing construct 
>>> without implementing full AWS capabilities and semantic (e.g. Shared 
>>> network isolation from VPC, or Floating IP scoping to VPC).
>>
>> A partial implementation is better then no implementation, that being
>> said if we want to overhaul OpenStack's VPC capabilities I think the
>> partial implementation would have to be thrown out.
> I agree too. However, given the choice, I would have preferred that we first 
> augment the neutron network access and sharing model before the building the 
> API. It stills qualify as partial implementation, but at least in the right 
> order.
>
>>
>>>   - Dependent blueprints are not implemented and have been deferred, 
>>> resulting in the broken implementation (e.g. 
>>> https://blueprints.launchpad.net/neutron/+spec/policy-extensions-for-neutron)
>>
>> That is a requirement for phase 3, and shouldn't matter for phase 1
>> and 2. And only phase 1 is up for review.
> My point is that it does matter a it gives users the feeling that they get 
> parity in term of isolation but they are not because of the missing isolation 
> and sharing constructs.
>
>>
>>>   - this "feature" is only available through EC2 API, which is likely going 
>>> to result in another implementation for general use.
>>>   - users adopting the VPC model proposed through EC2 API will be stuck in 
>>> an upgrade mess when the proper implementation comes along.
>>
>> This point concerns me the most, can you elaborate.
>
> First, while AWS does not support projects they do support, trough IAM, very 
> flexible policies for VPC resources access, see
> http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_IAM.html
> If we wanted to reproduce this in openstack, we could map this to levels in 
> the multi tenant hierarchy that Vish is proposing.
> However, because this project put all the resources in the same VPC project, 
> it's not possible anymore to implement the access policies without moving 
> resources between projects or recreating the VPC.

Thanks for the clarification.

>
>
>>
>>>   - There are new constructs in work that are better suited for 
>>> implementing this concept properly (Multi tenant hierarchy and domains).
>>
>>
>> All that being said, it sounds like there are two separate efforts to
>> get VPC into OpenStack, one by supporting AWS specs, and a second
>> native OpenStack version.  It sounds like further discussion is needed
>> between these two efforts, so I am unapproving
>> https://blueprints.launchpad.net/nova/+spec/aws-vpc-support as it
>> needs further discussion.  The last thing we want is to merge a
>> controversial blueprint before all the questions can be resolved.
>
> We should keep the discussion going as I'm sure that we can get to a better 
> proposal.

agreed.

>
> JC
> ___
> 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] VPC Proposal

[Harshad Nakil]

1. Feature is giving AWS VPC api compatibility with existing openstack
structure
2. It does give full AWS compatibility (except for network ACL which was
differed). Shared networks, FIP within scope of VPC is not some thing AWS
provides. So it is not partial support.
3. IMO it would not be major change to go from what we are proposing to
what JC is proposing as far as AWS VPC API(s) are concerned.
4. I can understand developers not liking AWS API(s) but many users of
openstack will benefit
5. Multi tenant hierarchy and domains won't effect AWS API(s) in any way

IMO there no need to differ this blueprint.



On Tue, Feb 18, 2014 at 10:03 AM, Martin, JC  wrote:

> There was a lot of emails on that thread, but I am not seeing the
> discussion converging. I would like to reiterate my concerns:
>
>- We are trying to implement an API on a feature that is not supported
> by openstack
>- As a result, the implementation is overloading existing construct
> without implementing full AWS capabilities and semantic (e.g. Shared
> network isolation from VPC, or Floating IP scoping to VPC).
>- Dependent blueprints are not implemented and have been deferred,
> resulting in the broken implementation (e.g.
> https://blueprints.launchpad.net/neutron/+spec/policy-extensions-for-neutron
> )
>- this "feature" is only available through EC2 API, which is likely
> going to result in another implementation for general use.
>- users adopting the VPC model proposed through EC2 API will be stuck
> in an upgrade mess when the proper implementation comes along.
>- There are new constructs in work that are better suited for
> implementing this concept properly (Multi tenant hierarchy and domains).
>
> As you can guess, I'm not really a fan, but it seems that only few
> individuals are concerned. I would think that this topic would create more
> interest, specially on the network side. Maybe because of the subject tags.
> I will therefore copy this email with the Neutron tag.
>
> JC
>
> On Feb 17, 2014, at 10:10 PM, Rudra Rugge  wrote:
>
> > I am not sure on how to dig out the archives. There were a couple of
> > emails exchanged with Salvatore on the thread pertaining to the
> extensions
> > we were referring to as part of this blueprint.
> >
> > There are a few notes on the whiteboard of the blueprint as well.
> >
> > Regards,
> > Rudra
> >
> >
> > On 2/17/14, 1:28 PM, "jc Martin"  wrote:
> >
> >> Thanks,
> >>
> >> Do you have the links for the discussions ?
> >>
> >> Thanks,
> >>
> >> JC
> >>
> >> Sent from my iPhone
> >>
> >>> On Feb 17, 2014, at 11:29 AM, Rudra Rugge  wrote:
> >>>
> >>> JC,
> >>>
> >>> BP has been updated with the correct links. I have removed the
> abandoned
> >>> review #3.
> >>> Please review #1 and #2.
> >>>
> >>> 1. https://review.openstack.org/#/c/40071/
> >>>
> >>>  This is the active review.
> >>>  There is one comment by Sean regarding
> >>>  adding a knob when Neutron is not used.
> >>>  That will be addressed with the next path.
> >>> 2. https://review.openstack.org/#/c/53171
> >>>  This is the active review for tempest
> >>>  test cases as requested by Joe Gordon.
> >>>  Currently abandoned until #1 goes through.
> >>> 3. https://review.openstack.org/#/c/53171
> >>>  This review is not active. It was accidentally submitted with a new
> >>> change-id.
> >>>
> >>> Regards,
> >>> Rudra
> >>>
>  On 2/16/14, 9:25 AM, "Martin, JC"  wrote:
> 
>  Harshad,
> 
>  I tried to find some discussion around this blueprint.
>  Could you provide us with some notes or threads  ?
> 
>  Also, about the code review you mention. which one are you talking
>  about :
>  https://review.openstack.org/#/c/40071/
>  https://review.openstack.org/#/c/49470/
>  https://review.openstack.org/#/c/53171
> 
>  because they are all abandoned.
> 
>  Could you point me to the code, and update the BP because it seems
> that
>  the links are not correct.
> 
>  Thanks,
> 
>  JC
> > On Feb 16, 2014, at 9:04 AM, "Allamaraju, Subbu" 
> > wrote:
> >
> > Harshad,
> >
> > Thanks for clarifying.
> >
> >> We started looking at this as some our customers/partners were
> >> interested in get AWS API compatibility. We have this blueprint and
> >> code review pending for long time now. We will know based on this
> >> thread wether the community is interested. But I assumed that
> >> community
> >> was interested as the blueprint was approved and code review has no
> >> -1(s) for long time now.
> >
> > Makes sense. I would leave it to others on this list to chime in if
> > there is sufficient interest or not.
> >
> >> To clarify, a clear incremental path from an AWS compatible API to
> an
> >> OpenStack model is not clear.
> >>
> >> In my mind AWS compatible API does not need new openstack model. As
> >> more discussion happen on JC's proposal and implementation b

Re: [openstack-dev] VPC Proposal

[Martin, JC]

Joe,

See my comments in line.

On Feb 18, 2014, at 12:26 PM, Joe Gordon  wrote:

> On Tue, Feb 18, 2014 at 10:03 AM, Martin, JC  wrote:
>> There was a lot of emails on that thread, but I am not seeing the discussion 
>> converging. I would like to reiterate my concerns:
>> 
>>   - We are trying to implement an API on a feature that is not supported by 
>> openstack
> 
> I don't see it that way. I see this BP as converting neutron calls
> into AWS VPC calls with a little glue (which can be seen here
> https://wiki.openstack.org/wiki/Blueprint-aws-vpc-support). But I am
> no networking expert, so take that with a large grain of salt.

If we had the supporting constructs, I would be in favor of implementing the 
AWS VPC features.

> 
>>   - As a result, the implementation is overloading existing construct 
>> without implementing full AWS capabilities and semantic (e.g. Shared network 
>> isolation from VPC, or Floating IP scoping to VPC).
> 
> A partial implementation is better then no implementation, that being
> said if we want to overhaul OpenStack's VPC capabilities I think the
> partial implementation would have to be thrown out.
I agree too. However, given the choice, I would have preferred that we first 
augment the neutron network access and sharing model before the building the 
API. It stills qualify as partial implementation, but at least in the right 
order.

> 
>>   - Dependent blueprints are not implemented and have been deferred, 
>> resulting in the broken implementation (e.g. 
>> https://blueprints.launchpad.net/neutron/+spec/policy-extensions-for-neutron)
> 
> That is a requirement for phase 3, and shouldn't matter for phase 1
> and 2. And only phase 1 is up for review.
My point is that it does matter a it gives users the feeling that they get 
parity in term of isolation but they are not because of the missing isolation 
and sharing constructs.

> 
>>   - this "feature" is only available through EC2 API, which is likely going 
>> to result in another implementation for general use.
>>   - users adopting the VPC model proposed through EC2 API will be stuck in 
>> an upgrade mess when the proper implementation comes along.
> 
> This point concerns me the most, can you elaborate.

First, while AWS does not support projects they do support, trough IAM, very 
flexible policies for VPC resources access, see 
http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_IAM.html
If we wanted to reproduce this in openstack, we could map this to levels in the 
multi tenant hierarchy that Vish is proposing.
However, because this project put all the resources in the same VPC project, 
it's not possible anymore to implement the access policies without moving 
resources between projects or recreating the VPC.


> 
>>   - There are new constructs in work that are better suited for implementing 
>> this concept properly (Multi tenant hierarchy and domains).
> 
> 
> All that being said, it sounds like there are two separate efforts to
> get VPC into OpenStack, one by supporting AWS specs, and a second
> native OpenStack version.  It sounds like further discussion is needed
> between these two efforts, so I am unapproving
> https://blueprints.launchpad.net/nova/+spec/aws-vpc-support as it
> needs further discussion.  The last thing we want is to merge a
> controversial blueprint before all the questions can be resolved.

We should keep the discussion going as I'm sure that we can get to a better 
proposal.

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

Re: [openstack-dev] VPC Proposal

[Joe Gordon]

On Tue, Feb 18, 2014 at 10:03 AM, Martin, JC  wrote:
> There was a lot of emails on that thread, but I am not seeing the discussion 
> converging. I would like to reiterate my concerns:
>
>- We are trying to implement an API on a feature that is not supported by 
> openstack

I don't see it that way. I see this BP as converting neutron calls
into AWS VPC calls with a little glue (which can be seen here
https://wiki.openstack.org/wiki/Blueprint-aws-vpc-support). But I am
no networking expert, so take that with a large grain of salt.

>- As a result, the implementation is overloading existing construct 
> without implementing full AWS capabilities and semantic (e.g. Shared network 
> isolation from VPC, or Floating IP scoping to VPC).

A partial implementation is better then no implementation, that being
said if we want to overhaul OpenStack's VPC capabilities I think the
partial implementation would have to be thrown out.

>- Dependent blueprints are not implemented and have been deferred, 
> resulting in the broken implementation (e.g. 
> https://blueprints.launchpad.net/neutron/+spec/policy-extensions-for-neutron)

That is a requirement for phase 3, and shouldn't matter for phase 1
and 2. And only phase 1 is up for review.

>- this "feature" is only available through EC2 API, which is likely going 
> to result in another implementation for general use.
>- users adopting the VPC model proposed through EC2 API will be stuck in 
> an upgrade mess when the proper implementation comes along.

This point concerns me the most, can you elaborate.

>- There are new constructs in work that are better suited for implementing 
> this concept properly (Multi tenant hierarchy and domains).


All that being said, it sounds like there are two separate efforts to
get VPC into OpenStack, one by supporting AWS specs, and a second
native OpenStack version.  It sounds like further discussion is needed
between these two efforts, so I am unapproving
https://blueprints.launchpad.net/nova/+spec/aws-vpc-support as it
needs further discussion.  The last thing we want is to merge a
controversial blueprint before all the questions can be resolved.

>
> As you can guess, I'm not really a fan, but it seems that only few 
> individuals are concerned. I would think that this topic would create more 
> interest, specially on the network side. Maybe because of the subject tags. I 
> will therefore copy this email with the Neutron tag.
>
> JC
>
> On Feb 17, 2014, at 10:10 PM, Rudra Rugge  wrote:
>
>> I am not sure on how to dig out the archives. There were a couple of
>> emails exchanged with Salvatore on the thread pertaining to the extensions
>> we were referring to as part of this blueprint.
>>
>> There are a few notes on the whiteboard of the blueprint as well.
>>
>> Regards,
>> Rudra
>>
>>
>> On 2/17/14, 1:28 PM, "jc Martin"  wrote:
>>
>>> Thanks,
>>>
>>> Do you have the links for the discussions ?
>>>
>>> Thanks,
>>>
>>> JC
>>>
>>> Sent from my iPhone
>>>
 On Feb 17, 2014, at 11:29 AM, Rudra Rugge  wrote:

 JC,

 BP has been updated with the correct links. I have removed the abandoned
 review #3.
 Please review #1 and #2.

 1. https://review.openstack.org/#/c/40071/

  This is the active review.
  There is one comment by Sean regarding
  adding a knob when Neutron is not used.
  That will be addressed with the next path.
 2. https://review.openstack.org/#/c/53171
  This is the active review for tempest
  test cases as requested by Joe Gordon.
  Currently abandoned until #1 goes through.
 3. https://review.openstack.org/#/c/53171
  This review is not active. It was accidentally submitted with a new
 change-id.

 Regards,
 Rudra

> On 2/16/14, 9:25 AM, "Martin, JC"  wrote:
>
> Harshad,
>
> I tried to find some discussion around this blueprint.
> Could you provide us with some notes or threads  ?
>
> Also, about the code review you mention. which one are you talking
> about :
> https://review.openstack.org/#/c/40071/
> https://review.openstack.org/#/c/49470/
> https://review.openstack.org/#/c/53171
>
> because they are all abandoned.
>
> Could you point me to the code, and update the BP because it seems that
> the links are not correct.
>
> Thanks,
>
> JC
>> On Feb 16, 2014, at 9:04 AM, "Allamaraju, Subbu" 
>> wrote:
>>
>> Harshad,
>>
>> Thanks for clarifying.
>>
>>> We started looking at this as some our customers/partners were
>>> interested in get AWS API compatibility. We have this blueprint and
>>> code review pending for long time now. We will know based on this
>>> thread wether the community is interested. But I assumed that
>>> community
>>> was interested as the blueprint was approved and code review has no
>>> -1(s) for long time now.
>>
>> Makes sense. I woul

Re: [openstack-dev] VPC Proposal

[Martin, JC]

There was a lot of emails on that thread, but I am not seeing the discussion 
converging. I would like to reiterate my concerns:

   - We are trying to implement an API on a feature that is not supported by 
openstack 
   - As a result, the implementation is overloading existing construct without 
implementing full AWS capabilities and semantic (e.g. Shared network isolation 
from VPC, or Floating IP scoping to VPC).
   - Dependent blueprints are not implemented and have been deferred, resulting 
in the broken implementation (e.g. 
https://blueprints.launchpad.net/neutron/+spec/policy-extensions-for-neutron)
   - this "feature" is only available through EC2 API, which is likely going to 
result in another implementation for general use.
   - users adopting the VPC model proposed through EC2 API will be stuck in an 
upgrade mess when the proper implementation comes along.
   - There are new constructs in work that are better suited for implementing 
this concept properly (Multi tenant hierarchy and domains).

As you can guess, I'm not really a fan, but it seems that only few individuals 
are concerned. I would think that this topic would create more interest, 
specially on the network side. Maybe because of the subject tags. I will 
therefore copy this email with the Neutron tag.

JC

On Feb 17, 2014, at 10:10 PM, Rudra Rugge  wrote:

> I am not sure on how to dig out the archives. There were a couple of
> emails exchanged with Salvatore on the thread pertaining to the extensions
> we were referring to as part of this blueprint.
> 
> There are a few notes on the whiteboard of the blueprint as well.
> 
> Regards,
> Rudra
> 
> 
> On 2/17/14, 1:28 PM, "jc Martin"  wrote:
> 
>> Thanks,
>> 
>> Do you have the links for the discussions ?
>> 
>> Thanks,
>> 
>> JC
>> 
>> Sent from my iPhone
>> 
>>> On Feb 17, 2014, at 11:29 AM, Rudra Rugge  wrote:
>>> 
>>> JC,
>>> 
>>> BP has been updated with the correct links. I have removed the abandoned
>>> review #3.
>>> Please review #1 and #2.
>>> 
>>> 1. https://review.openstack.org/#/c/40071/
>>> 
>>>  This is the active review.
>>>  There is one comment by Sean regarding
>>>  adding a knob when Neutron is not used.
>>>  That will be addressed with the next path.
>>> 2. https://review.openstack.org/#/c/53171
>>>  This is the active review for tempest
>>>  test cases as requested by Joe Gordon.
>>>  Currently abandoned until #1 goes through.
>>> 3. https://review.openstack.org/#/c/53171
>>>  This review is not active. It was accidentally submitted with a new
>>> change-id. 
>>> 
>>> Regards,
>>> Rudra
>>> 
 On 2/16/14, 9:25 AM, "Martin, JC"  wrote:
 
 Harshad,
 
 I tried to find some discussion around this blueprint.
 Could you provide us with some notes or threads  ?
 
 Also, about the code review you mention. which one are you talking
 about :
 https://review.openstack.org/#/c/40071/
 https://review.openstack.org/#/c/49470/
 https://review.openstack.org/#/c/53171
 
 because they are all abandoned.
 
 Could you point me to the code, and update the BP because it seems that
 the links are not correct.
 
 Thanks,
 
 JC
> On Feb 16, 2014, at 9:04 AM, "Allamaraju, Subbu" 
> wrote:
> 
> Harshad,
> 
> Thanks for clarifying.
> 
>> We started looking at this as some our customers/partners were
>> interested in get AWS API compatibility. We have this blueprint and
>> code review pending for long time now. We will know based on this
>> thread wether the community is interested. But I assumed that
>> community
>> was interested as the blueprint was approved and code review has no
>> -1(s) for long time now.
> 
> Makes sense. I would leave it to others on this list to chime in if
> there is sufficient interest or not.
> 
>> To clarify, a clear incremental path from an AWS compatible API to an
>> OpenStack model is not clear.
>> 
>> In my mind AWS compatible API does not need new openstack model. As
>> more discussion happen on JC's proposal and implementation becomes
>> clear we will know how incremental is the path. But at high level
>> there
>> two major differences
>> 1. New first class object will be introduced which effect all
>> components
>> 2. more than one project can be supported within VPC.
>> But it does not change AWS API(s). So even in JC(s) model if you want
>> AWS API then we will have to keep VPC to project mapping 1:1, since
>> the
>> API will not take both VPC ID and project ID.
>> 
>> As more users want to migrate from AWS or IaaS providers who want
>> compete with AWS should be interested in this compatibility.
> 
> IMHO that's a tough sell. Though an AWS compatible API does not need
> an
> OpenStack abstraction, we would end up with two independent ways of
> doing similar things. That would OpenStack repeating itself!
>>

Re: [openstack-dev] VPC Proposal

[Rudra Rugge]

I am not sure on how to dig out the archives. There were a couple of
emails exchanged with Salvatore on the thread pertaining to the extensions
we were referring to as part of this blueprint.

There are a few notes on the whiteboard of the blueprint as well.

Regards,
Rudra


On 2/17/14, 1:28 PM, "jc Martin"  wrote:

>Thanks,
>
>Do you have the links for the discussions ?
>
>Thanks,
>
>JC
>
>Sent from my iPhone
>
>> On Feb 17, 2014, at 11:29 AM, Rudra Rugge  wrote:
>> 
>> JC,
>> 
>> BP has been updated with the correct links. I have removed the abandoned
>> review #3.
>> Please review #1 and #2.
>> 
>> 1. https://review.openstack.org/#/c/40071/
>> 
>>   This is the active review.
>>   There is one comment by Sean regarding
>>   adding a knob when Neutron is not used.
>>   That will be addressed with the next path.
>> 2. https://review.openstack.org/#/c/53171
>>   This is the active review for tempest
>>   test cases as requested by Joe Gordon.
>>   Currently abandoned until #1 goes through.
>> 3. https://review.openstack.org/#/c/53171
>>   This review is not active. It was accidentally submitted with a new
>> change-id. 
>> 
>> Regards,
>> Rudra
>> 
>>> On 2/16/14, 9:25 AM, "Martin, JC"  wrote:
>>> 
>>> Harshad,
>>> 
>>> I tried to find some discussion around this blueprint.
>>> Could you provide us with some notes or threads  ?
>>> 
>>> Also, about the code review you mention. which one are you talking
>>>about :
>>> https://review.openstack.org/#/c/40071/
>>> https://review.openstack.org/#/c/49470/
>>> https://review.openstack.org/#/c/53171
>>> 
>>> because they are all abandoned.
>>> 
>>> Could you point me to the code, and update the BP because it seems that
>>> the links are not correct.
>>> 
>>> Thanks,
>>> 
>>> JC
 On Feb 16, 2014, at 9:04 AM, "Allamaraju, Subbu" 
wrote:
 
 Harshad,
 
 Thanks for clarifying.
 
> We started looking at this as some our customers/partners were
> interested in get AWS API compatibility. We have this blueprint and
> code review pending for long time now. We will know based on this
> thread wether the community is interested. But I assumed that
>community
> was interested as the blueprint was approved and code review has no
> -1(s) for long time now.
 
 Makes sense. I would leave it to others on this list to chime in if
 there is sufficient interest or not.
 
> To clarify, a clear incremental path from an AWS compatible API to an
> OpenStack model is not clear.
> 
> In my mind AWS compatible API does not need new openstack model. As
> more discussion happen on JC's proposal and implementation becomes
> clear we will know how incremental is the path. But at high level
>there
> two major differences
> 1. New first class object will be introduced which effect all
> components
> 2. more than one project can be supported within VPC.
> But it does not change AWS API(s). So even in JC(s) model if you want
> AWS API then we will have to keep VPC to project mapping 1:1, since
>the
> API will not take both VPC ID and project ID.
> 
> As more users want to migrate from AWS or IaaS providers who want
> compete with AWS should be interested in this compatibility.
 
 IMHO that's a tough sell. Though an AWS compatible API does not need
an
 OpenStack abstraction, we would end up with two independent ways of
 doing similar things. That would OpenStack repeating itself!
 
 Subbu
 
 
 
 ___
 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] VPC Proposal

[jc Martin]

Thanks,

Do you have the links for the discussions ?

Thanks,

JC

Sent from my iPhone

> On Feb 17, 2014, at 11:29 AM, Rudra Rugge  wrote:
> 
> JC,
> 
> BP has been updated with the correct links. I have removed the abandoned
> review #3.
> Please review #1 and #2.
> 
> 1. https://review.openstack.org/#/c/40071/
> 
>   This is the active review.
>   There is one comment by Sean regarding
>   adding a knob when Neutron is not used.
>   That will be addressed with the next path.
> 2. https://review.openstack.org/#/c/53171
>   This is the active review for tempest
>   test cases as requested by Joe Gordon.
>   Currently abandoned until #1 goes through.
> 3. https://review.openstack.org/#/c/53171
>   This review is not active. It was accidentally submitted with a new
> change-id. 
> 
> Regards,
> Rudra
> 
>> On 2/16/14, 9:25 AM, "Martin, JC"  wrote:
>> 
>> Harshad,
>> 
>> I tried to find some discussion around this blueprint.
>> Could you provide us with some notes or threads  ?
>> 
>> Also, about the code review you mention. which one are you talking about :
>> https://review.openstack.org/#/c/40071/
>> https://review.openstack.org/#/c/49470/
>> https://review.openstack.org/#/c/53171
>> 
>> because they are all abandoned.
>> 
>> Could you point me to the code, and update the BP because it seems that
>> the links are not correct.
>> 
>> Thanks,
>> 
>> JC
>>> On Feb 16, 2014, at 9:04 AM, "Allamaraju, Subbu"  wrote:
>>> 
>>> Harshad,
>>> 
>>> Thanks for clarifying.
>>> 
 We started looking at this as some our customers/partners were
 interested in get AWS API compatibility. We have this blueprint and
 code review pending for long time now. We will know based on this
 thread wether the community is interested. But I assumed that community
 was interested as the blueprint was approved and code review has no
 -1(s) for long time now.
>>> 
>>> Makes sense. I would leave it to others on this list to chime in if
>>> there is sufficient interest or not.
>>> 
 To clarify, a clear incremental path from an AWS compatible API to an
 OpenStack model is not clear.
 
 In my mind AWS compatible API does not need new openstack model. As
 more discussion happen on JC's proposal and implementation becomes
 clear we will know how incremental is the path. But at high level there
 two major differences
 1. New first class object will be introduced which effect all
 components
 2. more than one project can be supported within VPC.
 But it does not change AWS API(s). So even in JC(s) model if you want
 AWS API then we will have to keep VPC to project mapping 1:1, since the
 API will not take both VPC ID and project ID.
 
 As more users want to migrate from AWS or IaaS providers who want
 compete with AWS should be interested in this compatibility.
>>> 
>>> IMHO that's a tough sell. Though an AWS compatible API does not need an
>>> OpenStack abstraction, we would end up with two independent ways of
>>> doing similar things. That would OpenStack repeating itself!
>>> 
>>> Subbu
>>> 
>>> 
>>> 
>>> ___
>>> 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] VPC Proposal

[Rudra Rugge]

JC,

BP has been updated with the correct links. I have removed the abandoned
review #3.
Please review #1 and #2.

1. https://review.openstack.org/#/c/40071/

   This is the active review.
   There is one comment by Sean regarding
   adding a knob when Neutron is not used.
   That will be addressed with the next path.
2. https://review.openstack.org/#/c/53171
   This is the active review for tempest
   test cases as requested by Joe Gordon.
   Currently abandoned until #1 goes through.
3. https://review.openstack.org/#/c/53171
   This review is not active. It was accidentally submitted with a new
change-id. 

Regards,
Rudra

On 2/16/14, 9:25 AM, "Martin, JC"  wrote:

>Harshad,
>
>I tried to find some discussion around this blueprint.
>Could you provide us with some notes or threads  ?
>
>Also, about the code review you mention. which one are you talking about :
>https://review.openstack.org/#/c/40071/
>https://review.openstack.org/#/c/49470/
>https://review.openstack.org/#/c/53171
>
>because they are all abandoned.
>
>Could you point me to the code, and update the BP because it seems that
>the links are not correct.
>
>Thanks,
>
>JC
>On Feb 16, 2014, at 9:04 AM, "Allamaraju, Subbu"  wrote:
>
>> Harshad,
>> 
>> Thanks for clarifying.
>> 
>>> We started looking at this as some our customers/partners were
>>>interested in get AWS API compatibility. We have this blueprint and
>>>code review pending for long time now. We will know based on this
>>>thread wether the community is interested. But I assumed that community
>>>was interested as the blueprint was approved and code review has no
>>>-1(s) for long time now.
>> 
>> Makes sense. I would leave it to others on this list to chime in if
>>there is sufficient interest or not.
>> 
>>> To clarify, a clear incremental path from an AWS compatible API to an
>>>OpenStack model is not clear.
>>> 
>>> In my mind AWS compatible API does not need new openstack model. As
>>>more discussion happen on JC's proposal and implementation becomes
>>>clear we will know how incremental is the path. But at high level there
>>>two major differences
>>> 1. New first class object will be introduced which effect all
>>>components
>>> 2. more than one project can be supported within VPC.
>>> But it does not change AWS API(s). So even in JC(s) model if you want
>>>AWS API then we will have to keep VPC to project mapping 1:1, since the
>>>API will not take both VPC ID and project ID.
>>> 
>>> As more users want to migrate from AWS or IaaS providers who want
>>>compete with AWS should be interested in this compatibility.
>> 
>> IMHO that's a tough sell. Though an AWS compatible API does not need an
>>OpenStack abstraction, we would end up with two independent ways of
>>doing similar things. That would OpenStack repeating itself!
>> 
>> Subbu
>> 
>> 
>> 
>> ___
>> 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] VPC Proposal

[Ravi Chunduru]

IMO, VPC means to have managed set of resources not just limited to
networks but also projects.
I feel its not about incrementally starting with AWS compatibility, But
doing it right with AWS compatibility into consideration.

Thanks,
-Ravi.


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

> Comments Inline
>
> Regards
> -Harshad
>
>
> On Sat, Feb 15, 2014 at 11:39 PM, Allamaraju, Subbu wrote:
>
>> Harshad,
>>
>> Curious to know if there is a broad interest in an AWS compatible API in
>> the community?
>
>
> We started looking at this as some our customers/partners were interested
> in get AWS API compatibility. We have this blueprint and code review
> pending for long time now. We will know based on this thread wether the
> community is interested. But I assumed that community was interested as the
> blueprint was approved and code review has no -1(s) for long time now.
>
>
>> To clarify, a clear incremental path from an AWS compatible API to an
>> OpenStack model is not clear.
>>
>
> In my mind AWS compatible API does not need new openstack model. As more
> discussion happen on JC's proposal and implementation becomes clear we will
> know how incremental is the path. But at high level there two major
> differences
> 1. New first class object will be introduced which effect all components
> 2. more than one project can be supported within VPC.
> But it does not change AWS API(s). So even in JC(s) model if you want AWS
> API then we will have to keep VPC to project mapping 1:1, since the API
> will not take both VPC ID and project ID.
>
>



> As more users want to migrate from AWS or IaaS providers who want compete
> with AWS should be interested in this compatibility.
>
> There also seems to be terminology issue here Whats is definition of "VPC"
> if we assume what AWS implements is "VPC"
> then what JC is proposing "VOS" or "VDC" (virtual openstack or virtual DC)
> as all or most of current openstack features are available to user in  this
> new Abstraction. I actually like this new abstraction.
>
>
>> Subbu
>>
>> On Feb 15, 2014, at 10:04 PM, Harshad Nakil 
>> wrote:
>>
>> >
>> > I agree with problem as defined by you and will require more
>> fundamental changes.
>> > Meanwhile many users will benefit from AWS VPC api compatibility.
>>
>>
>> ___
>> 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
>
>


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

Re: [openstack-dev] VPC Proposal

[Martin, JC]

Harshad,

I tried to find some discussion around this blueprint.
Could you provide us with some notes or threads  ?

Also, about the code review you mention. which one are you talking about :
https://review.openstack.org/#/c/40071/
https://review.openstack.org/#/c/49470/
https://review.openstack.org/#/c/53171

because they are all abandoned.

Could you point me to the code, and update the BP because it seems that the 
links are not correct.

Thanks,

JC
On Feb 16, 2014, at 9:04 AM, "Allamaraju, Subbu"  wrote:

> Harshad,
> 
> Thanks for clarifying.
> 
>> We started looking at this as some our customers/partners were interested in 
>> get AWS API compatibility. We have this blueprint and code review pending 
>> for long time now. We will know based on this thread wether the community is 
>> interested. But I assumed that community was interested as the blueprint was 
>> approved and code review has no -1(s) for long time now.
> 
> Makes sense. I would leave it to others on this list to chime in if there is 
> sufficient interest or not.
> 
>> To clarify, a clear incremental path from an AWS compatible API to an 
>> OpenStack model is not clear.
>> 
>> In my mind AWS compatible API does not need new openstack model. As more 
>> discussion happen on JC's proposal and implementation becomes clear we will 
>> know how incremental is the path. But at high level there two major 
>> differences
>> 1. New first class object will be introduced which effect all components
>> 2. more than one project can be supported within VPC.
>> But it does not change AWS API(s). So even in JC(s) model if you want AWS 
>> API then we will have to keep VPC to project mapping 1:1, since the API will 
>> not take both VPC ID and project ID.
>> 
>> As more users want to migrate from AWS or IaaS providers who want compete 
>> with AWS should be interested in this compatibility.
> 
> IMHO that's a tough sell. Though an AWS compatible API does not need an 
> OpenStack abstraction, we would end up with two independent ways of doing 
> similar things. That would OpenStack repeating itself! 
> 
> Subbu
> 
> 
> 
> ___
> 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] VPC Proposal

[Harshad Nakil]

IMHO I don't see two implementations. Since right now we have only
one. As a community if we decide to add new abstractions then we will
have to change software in every component where the new abstraction
makes difference. That's normal software development process.
Regards
-Harshad


> On Feb 16, 2014, at 9:03 AM, "Allamaraju, Subbu"  wrote:
>
> Harshad,
>
> Thanks for clarifying.
>
>> We started looking at this as some our customers/partners were interested in 
>> get AWS API compatibility. We have this blueprint and code review pending 
>> for long time now. We will know based on this thread wether the community is 
>> interested. But I assumed that community was interested as the blueprint was 
>> approved and code review has no -1(s) for long time now.
>
> Makes sense. I would leave it to others on this list to chime in if there is 
> sufficient interest or not.
>
>> To clarify, a clear incremental path from an AWS compatible API to an 
>> OpenStack model is not clear.
>>
>> In my mind AWS compatible API does not need new openstack model. As more 
>> discussion happen on JC's proposal and implementation becomes clear we will 
>> know how incremental is the path. But at high level there two major 
>> differences
>> 1. New first class object will be introduced which effect all components
>> 2. more than one project can be supported within VPC.
>> But it does not change AWS API(s). So even in JC(s) model if you want AWS 
>> API then we will have to keep VPC to project mapping 1:1, since the API will 
>> not take both VPC ID and project ID.
>>
>> As more users want to migrate from AWS or IaaS providers who want compete 
>> with AWS should be interested in this compatibility.
>
> IMHO that's a tough sell. Though an AWS compatible API does not need an 
> OpenStack abstraction, we would end up with two independent ways of doing 
> similar things. That would OpenStack repeating itself!
>
> Subbu
>
>

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

Re: [openstack-dev] VPC Proposal

[Allamaraju, Subbu]

Harshad,

Thanks for clarifying.

> We started looking at this as some our customers/partners were interested in 
> get AWS API compatibility. We have this blueprint and code review pending for 
> long time now. We will know based on this thread wether the community is 
> interested. But I assumed that community was interested as the blueprint was 
> approved and code review has no -1(s) for long time now.

Makes sense. I would leave it to others on this list to chime in if there is 
sufficient interest or not.

> To clarify, a clear incremental path from an AWS compatible API to an 
> OpenStack model is not clear.
>  
> In my mind AWS compatible API does not need new openstack model. As more 
> discussion happen on JC's proposal and implementation becomes clear we will 
> know how incremental is the path. But at high level there two major 
> differences
> 1. New first class object will be introduced which effect all components
> 2. more than one project can be supported within VPC.
> But it does not change AWS API(s). So even in JC(s) model if you want AWS API 
> then we will have to keep VPC to project mapping 1:1, since the API will not 
> take both VPC ID and project ID.
> 
> As more users want to migrate from AWS or IaaS providers who want compete 
> with AWS should be interested in this compatibility.

IMHO that's a tough sell. Though an AWS compatible API does not need an 
OpenStack abstraction, we would end up with two independent ways of doing 
similar things. That would OpenStack repeating itself! 

Subbu



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

Re: [openstack-dev] VPC Proposal

[Harshad Nakil]

Comments Inline

Regards
-Harshad


On Sat, Feb 15, 2014 at 11:39 PM, Allamaraju, Subbu  wrote:

> Harshad,
>
> Curious to know if there is a broad interest in an AWS compatible API in
> the community?


We started looking at this as some our customers/partners were interested
in get AWS API compatibility. We have this blueprint and code review
pending for long time now. We will know based on this thread wether the
community is interested. But I assumed that community was interested as the
blueprint was approved and code review has no -1(s) for long time now.


> To clarify, a clear incremental path from an AWS compatible API to an
> OpenStack model is not clear.
>

In my mind AWS compatible API does not need new openstack model. As more
discussion happen on JC's proposal and implementation becomes clear we will
know how incremental is the path. But at high level there two major
differences
1. New first class object will be introduced which effect all components
2. more than one project can be supported within VPC.
But it does not change AWS API(s). So even in JC(s) model if you want AWS
API then we will have to keep VPC to project mapping 1:1, since the API
will not take both VPC ID and project ID.

As more users want to migrate from AWS or IaaS providers who want compete
with AWS should be interested in this compatibility.

There also seems to be terminology issue here Whats is definition of "VPC"
if we assume what AWS implements is "VPC"
then what JC is proposing "VOS" or "VDC" (virtual openstack or virtual DC)
as all or most of current openstack features are available to user in  this
new Abstraction. I actually like this new abstraction.


> Subbu
>
> On Feb 15, 2014, at 10:04 PM, Harshad Nakil 
> wrote:
>
> >
> > I agree with problem as defined by you and will require more fundamental
> changes.
> > Meanwhile many users will benefit from AWS VPC api compatibility.
>
>
> ___
> 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] VPC Proposal

[Allamaraju, Subbu]

Harshad,

Curious to know if there is a broad interest in an AWS compatible API in the 
community? To clarify, a clear incremental path from an AWS compatible API to 
an OpenStack model is not clear.

Subbu

On Feb 15, 2014, at 10:04 PM, Harshad Nakil  wrote:

> 
> I agree with problem as defined by you and will require more fundamental 
> changes.
> Meanwhile many users will benefit from AWS VPC api compatibility.


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

Re: [openstack-dev] VPC Proposal

[Allamaraju, Subbu]

True. The domain hierarchy isn't useful to capture resource sharing across a 
VPC. For instance, if a VPC admin would like to scope certain networks or 
images to a projects managed within a VPC, there isn't an abstraction today.

Subbu

On Feb 14, 2014, at 11:42 AM, Martin, JC  wrote:

> Arvind,
> 
> Thanks for point me to the blueprint. I'll add it to the related blueprints.
> 
> I think this could be part of the solution, but in addition to defining 
> administrative boundaries, we need to change the way object sharing works. 
> Today, there is only two levels : project private or public. You can share 
> objects between projects but there is no single model across openstack to 
> define resource scope, each component has a slightly different model. The VPC 
> implementation will also have to address that.
> 
> JC
> 
> On Feb 14, 2014, at 11:26 AM, "Tiwari, Arvind"  wrote:
> 
>> Hi JC,
>> 
>> I have proposed BP to address VPC using domain hierarchy and hierarchical 
>> administrative boundary.
>> 
>> https://blueprints.launchpad.net/keystone/+spec/hierarchical-administrative-boundary
>> 
>> 
>> Thanks,
>> Arvind
>> -Original Message-
>> From: Martin, JC [mailto:jch.mar...@gmail.com] 
>> Sent: Friday, February 14, 2014 12:09 PM
>> To: OpenStack Development Mailing List
>> Subject: [openstack-dev] VPC Proposal
>> 
>> 
>> There is a Blueprint targeted for Icehouse-3 that is aiming to implement the 
>> AWS VPC api. I don't think that this blueprint is providing the necessary 
>> constructs to really implement a VPC, and it is not taking into account the 
>> domains, or proposed multi tenant hierarchy. In addition, I could not find a 
>> discussion about this topic leading to the approval.
>> 
>> For this reason, I wrote an 'umbrella' blueprint to hopefully start the 
>> discussion on how to really implement VPC, and eventually split it into 
>> multiple real blueprints for each area.
>> 
>> Please, provide feedback on the following document, and on the best way to 
>> move this forward.
>> 
>> https://wiki.openstack.org/wiki/Blueprint-VPC
>> 
>> Thanks,
>> 
>> JC.
>> ___
>> 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] VPC Proposal

[Harshad Nakil]

Comments Inline

Regards
-Harshad


On Sat, Feb 15, 2014 at 3:18 PM, Martin, JC  wrote:

> Harshad,
>
> Thanks, What happens when I create two VPC ? Beside the project private
> networks, what is isolated ?
>

Since VPC is mapped to project. All the isolation provided by the project
is available.

>
> What do you call DC admin ? I know two administrators :
>- Cloud administrators
>- VPC admnistrator
>

I mean cloud administrator

>
> Are you saying that VPCs cannot have their own external gateways and NAT
> pools  ?
>

Yes conceptually as far as AWS API compatibility is concerned.

>
> Also, maybe more importantly, why try to build an AWS API before the
> function is available in openstack ? Why not wait to do it properly before
> defining the API mapping ?
>
Actually  as fas as AWS API is concerned we have all the proper building
blocks in openstack.

I agree with problem as defined by you and will require more fundamental
changes.
Meanwhile many users will benefit from AWS VPC api compatibility.

>
> JC
> On Feb 15, 2014, at 8:47 AM, Harshad Nakil 
> wrote:
>
> > EIP will be allocated from public pools. So in effect public pools and
> > shared networks are only DC admin functions. Not available to VPC
> > users.
> > There is a implicit external gateway. When one creates NAT instance or
> > VPN instance, external interfaces of these interfaces come from the
> > shared network which can be configured by the DC admin.
> >
> >
> > Regards
> > -Harshad
> >
> >
> >> On Feb 14, 2014, at 10:07 PM, "Martin, JC" 
> wrote:
> >>
> >> Harshad,
> >>
> >> I'm not sure to understand what you mean by :
> >>> However many of these concepts are not exposed to a AWS customers and
> >>> the API work well.
> >>
> >> So for example in :
> >>
> >>
> http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html#VPC_EIP_EC2_Differences
> >>
> >> When it says :
> >> "When you allocate an EIP, it's for use only in a VPC."
> >>
> >> Are you saying that the behavior of your API would be consistent
> without scoping the external networks to a VPC and using the public pool
> instead ?
> >>
> >> I believe that your api may work for basic features on a small
> deployments with only one VPC, but as soon as you have complex setups with
> external gateways that need to be isolated, I'm not sure that it will
> provide parity anyway with what EC2 provides.
> >>
> >>
> >> Maybe I missed something.
> >>
> >>
> >> JC
> >>
> >>> On Feb 14, 2014, at 7:35 PM, Harshad Nakil 
> wrote:
> >>>
> >>> Hi JC,
> >>>
> >>> You have put it aptly. Goal of the blueprint is to present facade for
> >>> AWS VPC API as the name suggest.
> >>> As per your definition of VPC, shared network will have issues.
> >>> However many of these concepts are not exposed to a AWS customers and
> >>> the API work well.
> >>> While we work incrementally towards your definition of VPC we can
> >>> maintain API compatibility to AWS API that we are proposing. As we are
> >>> subset of your proposal and don't expose all features within VPC.
> >>>
> >>> Regards
> >>> -Harshad
> >>>
> >>>
>  On Feb 14, 2014, at 6:22 PM, "Martin, JC" 
> wrote:
> 
>  Rudra,
> 
>  I do not agree that the current proposal provides the semantic of a
> VPC. If the goal is to only provide a facade through the EC2 API, it may
> address this, but unless you implement the basic features of a VPC, what
> good is it doing ?
> 
>  I do believe that the work can be done incrementally if we agree on
> the basic properties of a VPC, for example :
>  - allowing projects to be created while using resources defined at
> the VPC level
>  - preventing resources not explicitly defined at the VPC level to be
> used by a VPC.
> 
>  I do not see in the current proposal how resources are scoped to a
> VPC, and how, for example, you prevent shared network to be used within a
> VPC, or how you can define shared networks (or other shared resources) to
> only be scoped to a VPC.
> 
>  I think we already raised our concern to you several months ago, but
> it did not seem to have been addressed in the current proposal.
> 
>  thanks,
> 
>  JC
> 
> > On Feb 14, 2014, at 3:50 PM, Rudra Rugge  wrote:
> >
> > Hi JC,
> >
> > We agree with your proposed model of a VPC resource object. Proposal
> you are making makes sense to us and we would like to collaborate further
> on this. After reading your blueprint two things come to mind.
> >
> > 1. VPC vision for Openstack? (Your blueprint is proposing this
> vision)
> > 2. Providing AWS VPC api compatibility with current constrains of
> openstack structure.
> >
> > The blueprint that we proposed targets #2.
> > It gives a way to implement "AWS VPC api" compatible API. This helps
> subset of customers to migrate their workloads from AWS to openstack based
> clouds. In our implementation we tied VPC to project. That was easiest way
> to keep isolation with c

Re: [openstack-dev] VPC Proposal

[Martin, JC]

Harshad,

Thanks, What happens when I create two VPC ? Beside the project private 
networks, what is isolated ?

What do you call DC admin ? I know two administrators :
   - Cloud administrators
   - VPC admnistrator

Are you saying that VPCs cannot have their own external gateways and NAT pools  
?

Also, maybe more importantly, why try to build an AWS API before the function 
is available in openstack ? Why not wait to do it properly before defining the 
API mapping ?

JC
On Feb 15, 2014, at 8:47 AM, Harshad Nakil  wrote:

> EIP will be allocated from public pools. So in effect public pools and
> shared networks are only DC admin functions. Not available to VPC
> users.
> There is a implicit external gateway. When one creates NAT instance or
> VPN instance, external interfaces of these interfaces come from the
> shared network which can be configured by the DC admin.
> 
> 
> Regards
> -Harshad
> 
> 
>> On Feb 14, 2014, at 10:07 PM, "Martin, JC"  wrote:
>> 
>> Harshad,
>> 
>> I'm not sure to understand what you mean by :
>>> However many of these concepts are not exposed to a AWS customers and
>>> the API work well.
>> 
>> So for example in :
>> 
>> http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html#VPC_EIP_EC2_Differences
>> 
>> When it says :
>> "When you allocate an EIP, it's for use only in a VPC."
>> 
>> Are you saying that the behavior of your API would be consistent without 
>> scoping the external networks to a VPC and using the public pool instead ?
>> 
>> I believe that your api may work for basic features on a small deployments 
>> with only one VPC, but as soon as you have complex setups with external 
>> gateways that need to be isolated, I'm not sure that it will provide parity 
>> anyway with what EC2 provides.
>> 
>> 
>> Maybe I missed something.
>> 
>> 
>> JC
>> 
>>> On Feb 14, 2014, at 7:35 PM, Harshad Nakil  
>>> wrote:
>>> 
>>> Hi JC,
>>> 
>>> You have put it aptly. Goal of the blueprint is to present facade for
>>> AWS VPC API as the name suggest.
>>> As per your definition of VPC, shared network will have issues.
>>> However many of these concepts are not exposed to a AWS customers and
>>> the API work well.
>>> While we work incrementally towards your definition of VPC we can
>>> maintain API compatibility to AWS API that we are proposing. As we are
>>> subset of your proposal and don't expose all features within VPC.
>>> 
>>> Regards
>>> -Harshad
>>> 
>>> 
 On Feb 14, 2014, at 6:22 PM, "Martin, JC"  wrote:
 
 Rudra,
 
 I do not agree that the current proposal provides the semantic of a VPC. 
 If the goal is to only provide a facade through the EC2 API, it may 
 address this, but unless you implement the basic features of a VPC, what 
 good is it doing ?
 
 I do believe that the work can be done incrementally if we agree on the 
 basic properties of a VPC, for example :
 - allowing projects to be created while using resources defined at the VPC 
 level
 - preventing resources not explicitly defined at the VPC level to be used 
 by a VPC.
 
 I do not see in the current proposal how resources are scoped to a VPC, 
 and how, for example, you prevent shared network to be used within a VPC, 
 or how you can define shared networks (or other shared resources) to only 
 be scoped to a VPC.
 
 I think we already raised our concern to you several months ago, but it 
 did not seem to have been addressed in the current proposal.
 
 thanks,
 
 JC
 
> On Feb 14, 2014, at 3:50 PM, Rudra Rugge  wrote:
> 
> Hi JC,
> 
> We agree with your proposed model of a VPC resource object. Proposal you 
> are making makes sense to us and we would like to collaborate further on 
> this. After reading your blueprint two things come to mind.
> 
> 1. VPC vision for Openstack? (Your blueprint is proposing this vision)
> 2. Providing AWS VPC api compatibility with current constrains of 
> openstack structure.
> 
> The blueprint that we proposed targets #2.
> It gives a way to implement "AWS VPC api" compatible API. This helps 
> subset of customers to migrate their workloads from AWS to openstack 
> based clouds. In our implementation we tied VPC to project. That was 
> easiest way to keep isolation with current structure. We agree that what 
> you are proposing is more generic. One to way is to implement our current 
> proposal to have one VPC to one project mapping. As your blueprint 
> matures we will
> move VPC to multiple project mapping.
> 
> We feel that instead of throwing away all the work done we can take an 
> incremental approach.
> 
> Regards,
> Rudra
> 
> 
>> On Feb 14, 2014, at 11:09 AM, Martin, JC  wrote:
>> 
>> 
>> There is a Blueprint targeted for Icehouse-3 that is aiming to implement 
>> the AWS VPC api. I don't think that t

Re: [openstack-dev] VPC Proposal

[Harshad Nakil]

EIP will be allocated from public pools. So in effect public pools and
shared networks are only DC admin functions. Not available to VPC
users.
There is a implicit external gateway. When one creates NAT instance or
VPN instance, external interfaces of these interfaces come from the
shared network which can be configured by the DC admin.


Regards
-Harshad


> On Feb 14, 2014, at 10:07 PM, "Martin, JC"  wrote:
>
> Harshad,
>
> I'm not sure to understand what you mean by :
>> However many of these concepts are not exposed to a AWS customers and
>> the API work well.
>
> So for example in :
>
> http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html#VPC_EIP_EC2_Differences
>
> When it says :
> "When you allocate an EIP, it's for use only in a VPC."
>
> Are you saying that the behavior of your API would be consistent without 
> scoping the external networks to a VPC and using the public pool instead ?
>
> I believe that your api may work for basic features on a small deployments 
> with only one VPC, but as soon as you have complex setups with external 
> gateways that need to be isolated, I'm not sure that it will provide parity 
> anyway with what EC2 provides.
>
>
> Maybe I missed something.
>
>
> JC
>
>> On Feb 14, 2014, at 7:35 PM, Harshad Nakil  
>> wrote:
>>
>> Hi JC,
>>
>> You have put it aptly. Goal of the blueprint is to present facade for
>> AWS VPC API as the name suggest.
>> As per your definition of VPC, shared network will have issues.
>> However many of these concepts are not exposed to a AWS customers and
>> the API work well.
>> While we work incrementally towards your definition of VPC we can
>> maintain API compatibility to AWS API that we are proposing. As we are
>> subset of your proposal and don't expose all features within VPC.
>>
>> Regards
>> -Harshad
>>
>>
>>> On Feb 14, 2014, at 6:22 PM, "Martin, JC"  wrote:
>>>
>>> Rudra,
>>>
>>> I do not agree that the current proposal provides the semantic of a VPC. If 
>>> the goal is to only provide a facade through the EC2 API, it may address 
>>> this, but unless you implement the basic features of a VPC, what good is it 
>>> doing ?
>>>
>>> I do believe that the work can be done incrementally if we agree on the 
>>> basic properties of a VPC, for example :
>>> - allowing projects to be created while using resources defined at the VPC 
>>> level
>>> - preventing resources not explicitly defined at the VPC level to be used 
>>> by a VPC.
>>>
>>> I do not see in the current proposal how resources are scoped to a VPC, and 
>>> how, for example, you prevent shared network to be used within a VPC, or 
>>> how you can define shared networks (or other shared resources) to only be 
>>> scoped to a VPC.
>>>
>>> I think we already raised our concern to you several months ago, but it did 
>>> not seem to have been addressed in the current proposal.
>>>
>>> thanks,
>>>
>>> JC
>>>
 On Feb 14, 2014, at 3:50 PM, Rudra Rugge  wrote:

 Hi JC,

 We agree with your proposed model of a VPC resource object. Proposal you 
 are making makes sense to us and we would like to collaborate further on 
 this. After reading your blueprint two things come to mind.

 1. VPC vision for Openstack? (Your blueprint is proposing this vision)
 2. Providing AWS VPC api compatibility with current constrains of 
 openstack structure.

 The blueprint that we proposed targets #2.
 It gives a way to implement "AWS VPC api" compatible API. This helps 
 subset of customers to migrate their workloads from AWS to openstack based 
 clouds. In our implementation we tied VPC to project. That was easiest way 
 to keep isolation with current structure. We agree that what you are 
 proposing is more generic. One to way is to implement our current proposal 
 to have one VPC to one project mapping. As your blueprint matures we will
 move VPC to multiple project mapping.

 We feel that instead of throwing away all the work done we can take an 
 incremental approach.

 Regards,
 Rudra


> On Feb 14, 2014, at 11:09 AM, Martin, JC  wrote:
>
>
> There is a Blueprint targeted for Icehouse-3 that is aiming to implement 
> the AWS VPC api. I don't think that this blueprint is providing the 
> necessary constructs to really implement a VPC, and it is not taking into 
> account the domains, or proposed multi tenant hierarchy. In addition, I 
> could not find a discussion about this topic leading to the approval.
>
> For this reason, I wrote an 'umbrella' blueprint to hopefully start the 
> discussion on how to really implement VPC, and eventually split it into 
> multiple real blueprints for each area.
>
> Please, provide feedback on the following document, and on the best way 
> to move this forward.
>
> https://wiki.openstack.org/wiki/Blueprint-VPC
>
> Thanks,
>
> JC.
> __

Re: [openstack-dev] VPC Proposal

[Martin, JC]

Harshad,

I'm not sure to understand what you mean by :
> However many of these concepts are not exposed to a AWS customers and
> the API work well.

So for example in :

http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html#VPC_EIP_EC2_Differences

When it says : 
"When you allocate an EIP, it's for use only in a VPC."

Are you saying that the behavior of your API would be consistent without 
scoping the external networks to a VPC and using the public pool instead ?

I believe that your api may work for basic features on a small deployments with 
only one VPC, but as soon as you have complex setups with external gateways 
that need to be isolated, I'm not sure that it will provide parity anyway with 
what EC2 provides.


Maybe I missed something.


JC

On Feb 14, 2014, at 7:35 PM, Harshad Nakil  wrote:

> Hi JC,
> 
> You have put it aptly. Goal of the blueprint is to present facade for
> AWS VPC API as the name suggest.
> As per your definition of VPC, shared network will have issues.
> However many of these concepts are not exposed to a AWS customers and
> the API work well.
> While we work incrementally towards your definition of VPC we can
> maintain API compatibility to AWS API that we are proposing. As we are
> subset of your proposal and don't expose all features within VPC.
> 
> Regards
> -Harshad
> 
> 
>> On Feb 14, 2014, at 6:22 PM, "Martin, JC"  wrote:
>> 
>> Rudra,
>> 
>> I do not agree that the current proposal provides the semantic of a VPC. If 
>> the goal is to only provide a facade through the EC2 API, it may address 
>> this, but unless you implement the basic features of a VPC, what good is it 
>> doing ?
>> 
>> I do believe that the work can be done incrementally if we agree on the 
>> basic properties of a VPC, for example :
>>  - allowing projects to be created while using resources defined at the VPC 
>> level
>>  - preventing resources not explicitly defined at the VPC level to be used 
>> by a VPC.
>> 
>> I do not see in the current proposal how resources are scoped to a VPC, and 
>> how, for example, you prevent shared network to be used within a VPC, or how 
>> you can define shared networks (or other shared resources) to only be scoped 
>> to a VPC.
>> 
>> I think we already raised our concern to you several months ago, but it did 
>> not seem to have been addressed in the current proposal.
>> 
>> thanks,
>> 
>> JC
>> 
>>> On Feb 14, 2014, at 3:50 PM, Rudra Rugge  wrote:
>>> 
>>> Hi JC,
>>> 
>>> We agree with your proposed model of a VPC resource object. Proposal you 
>>> are making makes sense to us and we would like to collaborate further on 
>>> this. After reading your blueprint two things come to mind.
>>> 
>>> 1. VPC vision for Openstack? (Your blueprint is proposing this vision)
>>> 2. Providing AWS VPC api compatibility with current constrains of openstack 
>>> structure.
>>> 
>>> The blueprint that we proposed targets #2.
>>> It gives a way to implement "AWS VPC api" compatible API. This helps subset 
>>> of customers to migrate their workloads from AWS to openstack based clouds. 
>>> In our implementation we tied VPC to project. That was easiest way to keep 
>>> isolation with current structure. We agree that what you are proposing is 
>>> more generic. One to way is to implement our current proposal to have one 
>>> VPC to one project mapping. As your blueprint matures we will
>>> move VPC to multiple project mapping.
>>> 
>>> We feel that instead of throwing away all the work done we can take an 
>>> incremental approach.
>>> 
>>> Regards,
>>> Rudra
>>> 
>>> 
 On Feb 14, 2014, at 11:09 AM, Martin, JC  wrote:
 
 
 There is a Blueprint targeted for Icehouse-3 that is aiming to implement 
 the AWS VPC api. I don't think that this blueprint is providing the 
 necessary constructs to really implement a VPC, and it is not taking into 
 account the domains, or proposed multi tenant hierarchy. In addition, I 
 could not find a discussion about this topic leading to the approval.
 
 For this reason, I wrote an 'umbrella' blueprint to hopefully start the 
 discussion on how to really implement VPC, and eventually split it into 
 multiple real blueprints for each area.
 
 Please, provide feedback on the following document, and on the best way to 
 move this forward.
 
 https://wiki.openstack.org/wiki/Blueprint-VPC
 
 Thanks,
 
 JC.
 ___
 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.open

Re: [openstack-dev] VPC Proposal

[Harshad Nakil]

Hi JC,

You have put it aptly. Goal of the blueprint is to present facade for
AWS VPC API as the name suggest.
As per your definition of VPC, shared network will have issues.
However many of these concepts are not exposed to a AWS customers and
the API work well.
While we work incrementally towards your definition of VPC we can
maintain API compatibility to AWS API that we are proposing. As we are
subset of your proposal and don't expose all features within VPC.

Regards
-Harshad


> On Feb 14, 2014, at 6:22 PM, "Martin, JC"  wrote:
>
> Rudra,
>
> I do not agree that the current proposal provides the semantic of a VPC. If 
> the goal is to only provide a facade through the EC2 API, it may address 
> this, but unless you implement the basic features of a VPC, what good is it 
> doing ?
>
> I do believe that the work can be done incrementally if we agree on the basic 
> properties of a VPC, for example :
>   - allowing projects to be created while using resources defined at the VPC 
> level
>   - preventing resources not explicitly defined at the VPC level to be used 
> by a VPC.
>
> I do not see in the current proposal how resources are scoped to a VPC, and 
> how, for example, you prevent shared network to be used within a VPC, or how 
> you can define shared networks (or other shared resources) to only be scoped 
> to a VPC.
>
> I think we already raised our concern to you several months ago, but it did 
> not seem to have been addressed in the current proposal.
>
> thanks,
>
> JC
>
>> On Feb 14, 2014, at 3:50 PM, Rudra Rugge  wrote:
>>
>> Hi JC,
>>
>> We agree with your proposed model of a VPC resource object. Proposal you are 
>> making makes sense to us and we would like to collaborate further on this. 
>> After reading your blueprint two things come to mind.
>>
>> 1. VPC vision for Openstack? (Your blueprint is proposing this vision)
>> 2. Providing AWS VPC api compatibility with current constrains of openstack 
>> structure.
>>
>> The blueprint that we proposed targets #2.
>> It gives a way to implement "AWS VPC api" compatible API. This helps subset 
>> of customers to migrate their workloads from AWS to openstack based clouds. 
>> In our implementation we tied VPC to project. That was easiest way to keep 
>> isolation with current structure. We agree that what you are proposing is 
>> more generic. One to way is to implement our current proposal to have one 
>> VPC to one project mapping. As your blueprint matures we will
>> move VPC to multiple project mapping.
>>
>> We feel that instead of throwing away all the work done we can take an 
>> incremental approach.
>>
>> Regards,
>> Rudra
>>
>>
>>> On Feb 14, 2014, at 11:09 AM, Martin, JC  wrote:
>>>
>>>
>>> There is a Blueprint targeted for Icehouse-3 that is aiming to implement 
>>> the AWS VPC api. I don't think that this blueprint is providing the 
>>> necessary constructs to really implement a VPC, and it is not taking into 
>>> account the domains, or proposed multi tenant hierarchy. In addition, I 
>>> could not find a discussion about this topic leading to the approval.
>>>
>>> For this reason, I wrote an 'umbrella' blueprint to hopefully start the 
>>> discussion on how to really implement VPC, and eventually split it into 
>>> multiple real blueprints for each area.
>>>
>>> Please, provide feedback on the following document, and on the best way to 
>>> move this forward.
>>>
>>> https://wiki.openstack.org/wiki/Blueprint-VPC
>>>
>>> Thanks,
>>>
>>> JC.
>>> ___
>>> 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] VPC Proposal

[Martin, JC]

Rudra,

I do not agree that the current proposal provides the semantic of a VPC. If the 
goal is to only provide a facade through the EC2 API, it may address this, but 
unless you implement the basic features of a VPC, what good is it doing ?

I do believe that the work can be done incrementally if we agree on the basic 
properties of a VPC, for example :
   - allowing projects to be created while using resources defined at the VPC 
level
   - preventing resources not explicitly defined at the VPC level to be used by 
a VPC.

I do not see in the current proposal how resources are scoped to a VPC, and 
how, for example, you prevent shared network to be used within a VPC, or how 
you can define shared networks (or other shared resources) to only be scoped to 
a VPC.

I think we already raised our concern to you several months ago, but it did not 
seem to have been addressed in the current proposal.

thanks,

JC

On Feb 14, 2014, at 3:50 PM, Rudra Rugge  wrote:

> Hi JC,
> 
> We agree with your proposed model of a VPC resource object. Proposal you are 
> making makes sense to us and we would like to collaborate further on this. 
> After reading your blueprint two things come to mind.
> 
> 1. VPC vision for Openstack? (Your blueprint is proposing this vision)
> 2. Providing AWS VPC api compatibility with current constrains of openstack 
> structure.
> 
> The blueprint that we proposed targets #2. 
> It gives a way to implement "AWS VPC api" compatible API. This helps subset 
> of customers to migrate their workloads from AWS to openstack based clouds. 
> In our implementation we tied VPC to project. That was easiest way to keep 
> isolation with current structure. We agree that what you are proposing is 
> more generic. One to way is to implement our current proposal to have one VPC 
> to one project mapping. As your blueprint matures we will
> move VPC to multiple project mapping.
> 
> We feel that instead of throwing away all the work done we can take an 
> incremental approach.
> 
> Regards,
> Rudra
> 
> 
> On Feb 14, 2014, at 11:09 AM, Martin, JC  wrote:
> 
>> 
>> There is a Blueprint targeted for Icehouse-3 that is aiming to implement the 
>> AWS VPC api. I don't think that this blueprint is providing the necessary 
>> constructs to really implement a VPC, and it is not taking into account the 
>> domains, or proposed multi tenant hierarchy. In addition, I could not find a 
>> discussion about this topic leading to the approval.
>> 
>> For this reason, I wrote an 'umbrella' blueprint to hopefully start the 
>> discussion on how to really implement VPC, and eventually split it into 
>> multiple real blueprints for each area.
>> 
>> Please, provide feedback on the following document, and on the best way to 
>> move this forward.
>> 
>> https://wiki.openstack.org/wiki/Blueprint-VPC
>> 
>> Thanks,
>> 
>> JC.
>> ___
>> 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] VPC Proposal

[Rudra Rugge]

Hi JC,

We agree with your proposed model of a VPC resource object. Proposal you are 
making makes sense to us and we would like to collaborate further on this. 
After reading your blueprint two things come to mind.

1. VPC vision for Openstack? (Your blueprint is proposing this vision)
2. Providing AWS VPC api compatibility with current constrains of openstack 
structure.

The blueprint that we proposed targets #2. 
It gives a way to implement "AWS VPC api" compatible API. This helps subset of 
customers to migrate their workloads from AWS to openstack based clouds. In our 
implementation we tied VPC to project. That was easiest way to keep isolation 
with current structure. We agree that what you are proposing is more generic. 
One to way is to implement our current proposal to have one VPC to one project 
mapping. As your blueprint matures we will
move VPC to multiple project mapping.

We feel that instead of throwing away all the work done we can take an 
incremental approach.

Regards,
Rudra


On Feb 14, 2014, at 11:09 AM, Martin, JC  wrote:

> 
> There is a Blueprint targeted for Icehouse-3 that is aiming to implement the 
> AWS VPC api. I don't think that this blueprint is providing the necessary 
> constructs to really implement a VPC, and it is not taking into account the 
> domains, or proposed multi tenant hierarchy. In addition, I could not find a 
> discussion about this topic leading to the approval.
> 
> For this reason, I wrote an 'umbrella' blueprint to hopefully start the 
> discussion on how to really implement VPC, and eventually split it into 
> multiple real blueprints for each area.
> 
> Please, provide feedback on the following document, and on the best way to 
> move this forward.
> 
> https://wiki.openstack.org/wiki/Blueprint-VPC
> 
> Thanks,
> 
> JC.
> ___
> 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] VPC Proposal

[Martin, JC]

Joe,

I will let others comment, but since I think this BP was proposed much before 
the multi-tenant hierarchy BP, I would like to at least have the discussion. I 
would suggest a pause until we agree that this is ok to move this forward 
independently of the multi tenant hierarchy proposal.

JC

On Feb 14, 2014, at 11:42 AM, Joe Gordon  wrote:

> On Fri, Feb 14, 2014 at 12:09 PM, Martin, JC  wrote:
>> 
>> There is a Blueprint targeted for Icehouse-3 that is aiming to implement the 
>> AWS VPC api. I don't think that this blueprint is providing the necessary 
>> constructs to really implement a VPC, and it is not taking into account the 
>> domains, or proposed multi tenant hierarchy. In addition, I could not find a 
>> discussion about this topic leading to the approval.
> 
> Nova doesn't support keystone V3 domains or the proposed multi tenant
> hierarchy (proposed after this BP) yet. Do you think this BP should be
> blocked with those two as dependencies?
> 
>> 
>> For this reason, I wrote an 'umbrella' blueprint to hopefully start the 
>> discussion on how to really implement VPC, and eventually split it into 
>> multiple real blueprints for each area.
>> 
>> Please, provide feedback on the following document, and on the best way to 
>> move this forward.
>> 
>> https://wiki.openstack.org/wiki/Blueprint-VPC
>> 
>> Thanks,
>> 
>> JC.
>> ___
>> 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] VPC Proposal

[Martin, JC]

Arvind,

Thanks for point me to the blueprint. I'll add it to the related blueprints.

I think this could be part of the solution, but in addition to defining 
administrative boundaries, we need to change the way object sharing works. 
Today, there is only two levels : project private or public. You can share 
objects between projects but there is no single model across openstack to 
define resource scope, each component has a slightly different model. The VPC 
implementation will also have to address that.

JC

On Feb 14, 2014, at 11:26 AM, "Tiwari, Arvind"  wrote:

> Hi JC,
> 
> I have proposed BP to address VPC using domain hierarchy and hierarchical 
> administrative boundary.
> 
> https://blueprints.launchpad.net/keystone/+spec/hierarchical-administrative-boundary
> 
> 
> Thanks,
> Arvind
> -Original Message-
> From: Martin, JC [mailto:jch.mar...@gmail.com] 
> Sent: Friday, February 14, 2014 12:09 PM
> To: OpenStack Development Mailing List
> Subject: [openstack-dev] VPC Proposal
> 
> 
> There is a Blueprint targeted for Icehouse-3 that is aiming to implement the 
> AWS VPC api. I don't think that this blueprint is providing the necessary 
> constructs to really implement a VPC, and it is not taking into account the 
> domains, or proposed multi tenant hierarchy. In addition, I could not find a 
> discussion about this topic leading to the approval.
> 
> For this reason, I wrote an 'umbrella' blueprint to hopefully start the 
> discussion on how to really implement VPC, and eventually split it into 
> multiple real blueprints for each area.
> 
> Please, provide feedback on the following document, and on the best way to 
> move this forward.
> 
> https://wiki.openstack.org/wiki/Blueprint-VPC
> 
> Thanks,
> 
> JC.
> ___
> 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] VPC Proposal

[Joe Gordon]

On Fri, Feb 14, 2014 at 12:09 PM, Martin, JC  wrote:
>
> There is a Blueprint targeted for Icehouse-3 that is aiming to implement the 
> AWS VPC api. I don't think that this blueprint is providing the necessary 
> constructs to really implement a VPC, and it is not taking into account the 
> domains, or proposed multi tenant hierarchy. In addition, I could not find a 
> discussion about this topic leading to the approval.

Nova doesn't support keystone V3 domains or the proposed multi tenant
hierarchy (proposed after this BP) yet. Do you think this BP should be
blocked with those two as dependencies?

>
> For this reason, I wrote an 'umbrella' blueprint to hopefully start the 
> discussion on how to really implement VPC, and eventually split it into 
> multiple real blueprints for each area.
>
> Please, provide feedback on the following document, and on the best way to 
> move this forward.
>
> https://wiki.openstack.org/wiki/Blueprint-VPC
>
> Thanks,
>
> JC.
> ___
> 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] VPC Proposal

[Tiwari, Arvind]

Hi JC,

I have proposed BP to address VPC using domain hierarchy and hierarchical 
administrative boundary.

https://blueprints.launchpad.net/keystone/+spec/hierarchical-administrative-boundary


Thanks,
Arvind
-Original Message-
From: Martin, JC [mailto:jch.mar...@gmail.com] 
Sent: Friday, February 14, 2014 12:09 PM
To: OpenStack Development Mailing List
Subject: [openstack-dev] VPC Proposal


There is a Blueprint targeted for Icehouse-3 that is aiming to implement the 
AWS VPC api. I don't think that this blueprint is providing the necessary 
constructs to really implement a VPC, and it is not taking into account the 
domains, or proposed multi tenant hierarchy. In addition, I could not find a 
discussion about this topic leading to the approval.

For this reason, I wrote an 'umbrella' blueprint to hopefully start the 
discussion on how to really implement VPC, and eventually split it into 
multiple real blueprints for each area.

Please, provide feedback on the following document, and on the best way to move 
this forward.

https://wiki.openstack.org/wiki/Blueprint-VPC

Thanks,

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