Open Stack

Hi Ryan:

As I stated in the patch review, the suggestion to use a "profiled API"
like IETF/CCITT is indeed very interesting. As a "profiled API" has not
been tried with any neutron model before, and as there is no existing
design pattern/best practices for how best to structure that, my
recommendation is to create a new patch (dependent on this patch) to try
that experiment.

That patch will also clarify what is meant you mean by a "profiled API" and
how that might interact with other openstack services like Heat and Horizon.

Regards,
Mandeep
-----



On Wed, Jul 30, 2014 at 11:13 AM, Hemanth Ravi <hemanthraviml at gmail.com>
wrote:

> 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
>>
>>
>
> _______________________________________________
> 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/3a75e3e4/attachment.html>