Open Stack

I don't think another extension is needed. Beyond the CLI, very limited
changes (additions) in the model/db such as those I suggested in [1] can be
helpful and will minimize the changes needed on the client side.

Best,

Mohammad

[1] https://review.openstack.org/#/c/103755/ (Patch Set 3)



From:	Kevin Benton <blak111 at gmail.com>
To:	"OpenStack Development Mailing List (not for usage questions)"
            <openstack-dev at lists.openstack.org>
Date:	07/31/2014 03:01 AM
Subject:	Re: [openstack-dev] [neutron][policy] Bridging the 2-group gap
            in group policy



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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140731/df1ce6e7/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140731/df1ce6e7/attachment.gif>