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
