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