Open Stack

1. Feature is giving AWS VPC api compatibility with existing openstack
structure
2. It does give full AWS compatibility (except for network ACL which was
differed). Shared networks, FIP within scope of VPC is not some thing AWS
provides. So it is not partial support.
3. IMO it would not be major change to go from what we are proposing to
what JC is proposing as far as AWS VPC API(s) are concerned.
4. I can understand developers not liking AWS API(s) but many users of
openstack will benefit
5. Multi tenant hierarchy and domains won't effect AWS API(s) in any way

IMO there no need to differ this blueprint.



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
>    - 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 <rrugge at 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.martin at 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 <rrugge at 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.martin at 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" <subbu at 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 at lists.openstack.org
> >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> OpenStack-dev mailing list
> >>>> OpenStack-dev at lists.openstack.org
> >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> OpenStack-dev mailing list
> >>> OpenStack-dev at lists.openstack.org
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >> _______________________________________________
> >> OpenStack-dev mailing list
> >> OpenStack-dev at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >>
> >
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140218/eaed245b/attachment.html>