Open Stack

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

agreed.

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