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 <blak...@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" <dh...@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 <hemanthrav...@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 <rmo...@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@lists.openstack.org >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>> >>> >>> _______________________________________________ >>> OpenStack-dev mailing list >>> OpenStack-dev@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
