On Tue, Feb 18, 2014 at 1:01 PM, Martin, JC <jch.mar...@gmail.com> wrote:
> Joe,
> See my comments in line.
> On Feb 18, 2014, at 12:26 PM, Joe Gordon <joe.gord...@gmail.com> wrote:
>> On Tue, Feb 18, 2014 at 10:03 AM, Martin, JC <jch.mar...@gmail.com> 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.


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

OpenStack-dev mailing list

Reply via email to