<html><body>
<p><font size="2" 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 size="2" 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 size="2" 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 size="2" 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 size="2" face="sans-serif">were added, but without changing the basic use case requirements from the original document. A followup meeting [5]</font><br>
<font size="2" 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 size="2" 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 size="2" face="sans-serif">resulting PoC code.</font><br>
<br>
<font size="2" 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 size="2" 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 size="2" 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 size="2" 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 size="2" face="sans-serif">common ways. In this case, what I'm envisioning is something like</font><br>
<br>
<font size="2" face="sans-serif">neutron policy-apply [policy rule] [src group] [destination group]</font><br>
<br>
<font size="2" 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 size="2" 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 size="2" 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 size="2" face="sans-serif">to specify policy as something between two groups.</font><br>
<br>
<font size="2" face="sans-serif">Ryan Moats (regXboi)</font><br>
<br>
<font size="2" face="sans-serif">References:</font><br>
<font size="2" face="sans-serif">[1] </font><a href="http://eavesdrop.openstack.org/meetings/networking/2014/networking.2014-07-28-21.02.log.txt"><font size="2" face="sans-serif">http://eavesdrop.openstack.org/meetings/networking/2014/networking.2014-07-28-21.02.log.txt</font></a><br>
<font size="2" face="sans-serif">[2] </font><a href="https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIrupCD9E/edit#"><font size="2" face="sans-serif">https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIrupCD9E/edit#</font></a><br>
<font size="2" face="sans-serif">[3] </font><a href="http://lists.openstack.org/pipermail/openstack-dev/2013-December/022150.html"><font size="2" face="sans-serif">http://lists.openstack.org/pipermail/openstack-dev/2013-December/022150.html</font></a><br>
<font size="2" face="sans-serif">[4] </font><a href="http://eavesdrop.openstack.org/meetings/networking_policy/2014/networking_policy.2014-02-27-19.00.log.html"><font size="2" face="sans-serif">http://eavesdrop.openstack.org/meetings/networking_policy/2014/networking_policy.2014-02-27-19.00.log.html</font></a><br>
<font size="2" face="sans-serif">[5] </font><a href="http://eavesdrop.openstack.org/meetings/networking_policy/2014/networking_policy.2014-03-20-19.00.log.html"><font size="2" face="sans-serif">http://eavesdrop.openstack.org/meetings/networking_policy/2014/networking_policy.2014-03-20-19.00.log.html</font></a><br>
<font size="2" face="sans-serif">[6] </font><a href="http://lists.openstack.org/pipermail/openstack-dev/2014-May/035661.html"><font size="2" face="sans-serif">http://lists.openstack.org/pipermail/openstack-dev/2014-May/035661.html</font></a><br>
<font size="2" face="sans-serif">[7] </font><a href="http://eavesdrop.openstack.org/meetings/networking_policy/2014/networking_policy.2014-05-22-18.01.log.html"><font size="2" face="sans-serif">http://eavesdrop.openstack.org/meetings/networking_policy/2014/networking_policy.2014-05-22-18.01.log.html</font></a><br>
<font size="2" face="sans-serif">[8] </font><a href="https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy"><font size="2" face="sans-serif">https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy</font></a></body></html>