Open Stack

I am one of the developers on the project, so I have a strong preference
for option (1).

I think a 3rd option is also possible, which offers a scale down version of
GBP APIs. Contracts could be added in kilo. Provide EndPoints,
EndPointGroups, Rules and Policies. This is the simpler approach suggested
in GBP document, where you have a policy with a single rule (classifier &
action) applied between 2 EPGs. This approach minimizes complexity and
therefore saves precious reviewer's time. This requires some code reorg,
which may not be preferable to other developers on the project.

Alternatively, contracts could be added as optional vendor extensions in
Juno.



On Wed, Aug 6, 2014 at 8:50 PM, Alan Kavanagh <alan.kavanagh at ericsson.com>
wrote:

> +1
> I believe Pedro has a very valid point here, and that is the "the
> community to approve the spec and that decision should be respected". It
> makes sense to again clearly denote the "process and governance" and have
> this noted on the thread Stefano started earlier today.
>
> /Alan
>
> -----Original Message-----
> From: Pedro Marques [mailto:pedro.r.marques at gmail.com]
> Sent: August-06-14 4:52 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the
> way forward
>
>
> On Aug 6, 2014, at 1:27 PM, Jay Pipes <jaypipes at gmail.com> wrote:
> >
> > However, it seems to me that the end-goal of the GBP effort is
> *actually* to provide a higher-layer API to Neutron that would essentially
> enable proprietary vendors to entirely swap out all of Neutron core for a
> new set of drivers that spoke proprietary device APIs.
> >
> > If this is the end-goal, it should be stated more clearly, IMO.
>
> I believe that people should be considered innocent until proven
> otherwise. Is there a reason to believe there is some hidden reason behind
> this proposal ? It seems to me that this is uncalled for.
>
> Neutron allows vendors to speak to proprietary device APIs, it was
> designed to do so, AFAIK. It is also possibly to "entirely swap out all of
> the Neutron core"... the proponents of the group based policy didn't have
> to go through so much trouble if that was their intent. As far as i know
> most plugins talk to a proprietary API.
>
> I happen to disagree technically with a couple of choices made by this
> proposal; but the blueprint was approved. Which means that i lost the
> argument, or didn't raise it on time, or didn't argue convincingly...
> regardless of the reason, the time to argue about the goal has passed. The
> decision of the community was to approve the spec and that decision should
> be respected.
>
>   Pedro.
> _______________________________________________
> 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
>



-- 

Thanks
OSM
(Subrahmanyam Ongole)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140806/a46283a8/attachment.html>