<div dir="ltr">Hi,<div><br></div><div>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.</div>
<div><br></div><div>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.</div><div><br></div><div>Thanks,</div>
<div>-hemanth</div><div><br></div><div>[1] <a href="https://review.openstack.org/#/c/104013">https://review.openstack.org/#/c/104013</a></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jul 29, 2014 at 3:16 PM, Ryan Moats <span dir="ltr"><<a href="mailto:rmoats@us.ibm.com" target="_blank">rmoats@us.ibm.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
<p><font face="sans-serif">As promised in Monday's Neutron IRC minutes [1], this mail is a "trip down memory lane" looking at the history of the</font><br>
<font face="sans-serif">Neutron GP project.. The original GP google doc [2] included specifying policy via both a produce/consume 1-group</font><br>
<font face="sans-serif">approach and as a link between two groups. There was an email thread [3] that discussed the relationship between</font><br>
<font face="sans-serif">these models early on, but that discussion petered out and during a later IRC meeting [4] the concept of contracts</font><br>
<font face="sans-serif">were added, but without changing the basic use case requirements from the original document. A followup meeting [5]</font><br>
<font face="sans-serif">began the discussion of how to express the original model from the contract data model but that discussion doesn't</font><br>
<font face="sans-serif">appear to have been completed either. The PoC in Atlanta raised a set of issues [6],[7] around the complexity of the</font><br>
<font face="sans-serif">resulting PoC code.</font><br>
<br>
<font face="sans-serif">The good news is that having looked through the proposed GP code commits (links to which can be found at [8) I</font><br>
<font face="sans-serif">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</font><br>
<font face="sans-serif">that without changing the model encoded in those commits. Rather, it can be done via the WiP CLI code commit by</font><br>
<font face="sans-serif">providing a "profiled" API - this is a technique used by the IETF, CCITT, etc. to allow a rich API to be consumed in</font><br>
<font face="sans-serif">common ways. In this case, what I'm envisioning is something like</font><br>
<br>
<font face="sans-serif">neutron policy-apply [policy rule] [src group] [destination group]</font><br>
<br>
<font face="sans-serif">in this case, the CLI would perform the contract creation for the policy rule, and assigning the proper produce/consume</font><br>
<font face="sans-serif">edits to the specified source and destination groups. Note: this is in addition to the CLI providing direct access to the</font><br>
<font face="sans-serif">underlying data model. I believe that this is the simplest way to "bridge the gap" and provide support to folks who want</font><br>
<font face="sans-serif">to specify policy as something between two groups.</font><br>
<br>
<font face="sans-serif">Ryan Moats (regXboi)</font><br>
<br>
<font face="sans-serif">References:</font><br>
<font face="sans-serif">[1] </font><a href="http://eavesdrop.openstack.org/meetings/networking/2014/networking.2014-07-28-21.02.log.txt" target="_blank"><font face="sans-serif">http://eavesdrop.openstack.org/meetings/networking/2014/networking.2014-07-28-21.02.log.txt</font></a><br>
<font face="sans-serif">[2] </font><a href="https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIrupCD9E/edit#" target="_blank"><font face="sans-serif">https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIrupCD9E/edit#</font></a><br>
<font face="sans-serif">[3] </font><a href="http://lists.openstack.org/pipermail/openstack-dev/2013-December/022150.html" target="_blank"><font face="sans-serif">http://lists.openstack.org/pipermail/openstack-dev/2013-December/022150.html</font></a><br>
<font face="sans-serif">[4] </font><a href="http://eavesdrop.openstack.org/meetings/networking_policy/2014/networking_policy.2014-02-27-19.00.log.html" target="_blank"><font face="sans-serif">http://eavesdrop.openstack.org/meetings/networking_policy/2014/networking_policy.2014-02-27-19.00.log.html</font></a><br>
<font face="sans-serif">[5] </font><a href="http://eavesdrop.openstack.org/meetings/networking_policy/2014/networking_policy.2014-03-20-19.00.log.html" target="_blank"><font face="sans-serif">http://eavesdrop.openstack.org/meetings/networking_policy/2014/networking_policy.2014-03-20-19.00.log.html</font></a><br>
<font face="sans-serif">[6] </font><a href="http://lists.openstack.org/pipermail/openstack-dev/2014-May/035661.html" target="_blank"><font face="sans-serif">http://lists.openstack.org/pipermail/openstack-dev/2014-May/035661.html</font></a><br>
<font face="sans-serif">[7] </font><a href="http://eavesdrop.openstack.org/meetings/networking_policy/2014/networking_policy.2014-05-22-18.01.log.html" target="_blank"><font face="sans-serif">http://eavesdrop.openstack.org/meetings/networking_policy/2014/networking_policy.2014-05-22-18.01.log.html</font></a><br>
<font face="sans-serif">[8] </font><a href="https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy" target="_blank"><font face="sans-serif">https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy</font></a></p>
</div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>