Open Stack

Thanks Kevin and others for the input here. We have put this on
today's Group Policy IRC meeting agenda:
https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy#July_31st.2C_2014

On Wed, Jul 30, 2014 at 11:59 PM, Kevin Benton <blak111 at gmail.com> wrote:
> I agree. Ryan, can you propose a patch based off of the existing group
> policy work so we can get an idea of what changes are required to implement
> this level of abstraction?
>
> It sounds like this is work that can be built entirely on top of the
> existing abstractions and APIs offered by the current GBP work. If that's
> the case, it could be contained in the CLI or possibly introduced in another
> extension if it requires too much complexity in the client.
>
> Cheers,
> --
> Kevin Benton
>
> On Jul 30, 2014 12:25 PM, "Mandeep Dhami" <dhami at noironetworks.com> wrote:
>>
>> 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
>>>
>>
>>
>> _______________________________________________
>> 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
>