Open Stack

Hi,

Adding this CLI command seems to be a good way to provide support for the
second model. This can be submitted as a new review patch to work through
the approaches to implement this. I suggest the current CLI patch [1] be
reviewed for the existing spec and completed.

Ryan, would it possible for you to start a new review submit for the new
command(s). Could you also provide any references for "profiled" API in
IETF, CCITT.

Thanks,
-hemanth

[1] https://review.openstack.org/#/c/104013


On Tue, Jul 29, 2014 at 3:16 PM, Ryan Moats <rmoats at us.ibm.com> wrote:

> As promised in Monday's Neutron IRC minutes [1], this mail is a "trip down
> memory lane" looking at the history of the
> Neutron GP project..  The original GP google doc [2] included specifying
> policy via both a produce/consume 1-group
> approach and as a link between two groups.  There was an email thread [3]
> that discussed the relationship between
> these models early on, but that discussion petered out and during a later
> IRC meeting [4] the concept of contracts
> were added, but without changing the basic use case requirements from the
> original document.  A followup meeting [5]
> began the discussion of how to express the original model from the
> contract data model but that discussion doesn't
> appear to have been completed either.  The PoC in Atlanta raised a set of
> issues [6],[7] around the complexity of the
> resulting PoC code.
>
> The good news is that having looked through the proposed GP code commits
> (links to which can be found at [8) I
> believe that folks that want to be able to specify policies via the
> 2-group approach (and yes, I'm one of them) can have
> that without changing the model encoded in those commits. Rather, it can
> be done via the WiP CLI code commit by
> providing a "profiled" API - this is a technique used by the IETF, CCITT,
> etc. to allow a rich API to be consumed in
> common ways.  In this case, what I'm envisioning is something like
>
> neutron policy-apply [policy rule] [src group] [destination group]
>
> in this case, the CLI would perform the contract creation for the policy
> rule, and assigning the proper produce/consume
> edits to the specified source and destination groups.  Note:  this is in
> addition to the CLI providing direct access to the
> underlying data model.  I believe that this is the simplest way to "bridge
> the gap" and provide support to folks who want
> to specify policy as something between two groups.
>
> Ryan Moats (regXboi)
>
> References:
> [1]
> http://eavesdrop.openstack.org/meetings/networking/2014/networking.2014-07-28-21.02.log.txt
> [2]
> https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIrupCD9E/edit#
> [3]
> http://lists.openstack.org/pipermail/openstack-dev/2013-December/022150.html
> [4]
> http://eavesdrop.openstack.org/meetings/networking_policy/2014/networking_policy.2014-02-27-19.00.log.html
> [5]
> http://eavesdrop.openstack.org/meetings/networking_policy/2014/networking_policy.2014-03-20-19.00.log.html
> [6]
> http://lists.openstack.org/pipermail/openstack-dev/2014-May/035661.html
> [7]
> http://eavesdrop.openstack.org/meetings/networking_policy/2014/networking_policy.2014-05-22-18.01.log.html
> [8] https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy
>
> _______________________________________________
> 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/20140730/f155546f/attachment.html>