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