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 <rru...@juniper.net> 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" <jch.mar...@gmail.com> 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 <rru...@juniper.net> 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" <jch.mar...@gmail.com> 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" <su...@subbu.org> >>>>> 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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
