Open Stack

Inline.

----- Original Message -----
| From: "Mohammad Banikazemi" <mb at us.ibm.com>
| To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
| Cc: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
| Sent: Tuesday, December 17, 2013 11:42:53 AM
| Subject: Re: [openstack-dev] [neutron] [policy] Policy-group relationship
| 
| 
| 
| 
| Stephen Wong <s3wong at midokura.com> wrote on 12/15/2013 12:00:32 PM:
| 
| > From: Stephen Wong <s3wong at midokura.com>
| > To: "OpenStack Development Mailing List (not for usage questions)"
| > <openstack-dev at lists.openstack.org>,
| > Date: 12/15/2013 12:04 PM
| > Subject: Re: [openstack-dev] [neutron] [policy] Policy-group
| > relationship
| > 
| > Hi Mohammad,
| > 
| > Good writeup, one minor comment at the end below (look for
| > [s3wong]).
| > 
| > On Thu, Dec 12, 2013 at 3:42 PM, Mohammad Banikazemi
| > <mb at us.ibm.com> wrote:
| > > Continuing the discussion we had earlier today during the Neutron
| > > Group
| > > Policy weekly meeting [0], I would like to initiate a couple of
| > > email
| > > threads and follow up on a couple of important issues we need to
| > > agree on so
| > > we can move forward. In this email thread, I would like to
| > > discuss the
| > > policy-group relationship.
| > > 
| > > I want to summarize the discussion we had during the meeting [1]
| > > and see if
| > > we have reached an agreement:
| > > 
| > > There are two models for expressing the relationship between
| > > Groups and
| > > Policies that were discussed:
| > > 1- Policies are defined for a source Group and a destination
| > > Group
| > > 2- Groups specify the Policies they "provide" and the Policies
| > > they
| > > "consume"
| > > 
| > > As expressed during the IRC meeting, both models have strong
| > > support and we
| > > decided to have a resource model that can be used to express both
| > > models.
| > > The solution we came up with was rather simple:
| > > 
| > > Update the resource model (shown in the attribute tables and the
| > > taxonomy in
| > > the google doc [2]) such that policy can refer to a "list" of
| > > source Groups
| > > and a "list" of destination Groups.
| > > This boils down to having two attributes namely, src_groups and
| > > destination_groups (both list of uuid-str type) replacing the
| > > current
| > > attributes src_group and dest_group, respectively.
| > > 
| > > This change simply allows the support for both models. For
| > > supporting model
| > > 1, specify a single source Group and a single destination Group.
| > > For model
| > > 2, specify the producers of a Policy in the source Group list and
| > > specify
| > > the consumers of the Policy in the destination Group list.
| > 
| > [s3wong] this is interesting. Let's say we have two groups A & B,
| > and
| > A wants to send traffic to B, so in this case, B is providing a
| > policy
| > which A will consume. In your proposal above, I would have to put A
| > in
| > destination group list and B in source group list although the
| > traffic
| > direction is the reverse. Would that cause a bit of a confusion?
| > 
| 
| Yeah, that's a good point. Producers are the destination of traffic
| flows.
| So should we have them under destination group? Even that is a bit
| confusing.
| May be we need different names for the two groups.
| 
| -Mohammad
| 

If we're not sure what the 2 groups represent (source and destination), perhaps that means we ought to have any number of groups and not assign them names.  A policy would then be applied to any number of groups, and it would be up to the policy itself to dictate source/destination semantics if that is what the groups represent.

For example, if we had a DENY action, it might take several arguments, one of which is a source and one of which is a destination.  Then by applying groups properly to that DENY action, we could dictate which group is playing the role of SOURCE and which group is playing the role of DESTINATION.

Tim

| > Thanks,
| > - Stephen
| > 
| > 
| > > 
| > > If there is agreement, I will update the taxonomy and the
| > > attribute tables
| > > in the doc.
| > > 
| > > Best,
| > > 
| > > Mohammad
| > > 
| > > 
| > > [0] https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy
| > > [1]
| > > http://eavesdrop.openstack.org/meetings/networking_policy/2013/
| > networking_policy.2013-12-12-16.01.log.html
| > > [2]
| > > https://docs.google.com/document/d/
| > 1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIrupCD9E/edit#heading=h.x1h06xqhlo1n
| > > (Note the new additions are at the end of the document.)
| > > 
| > > 
| > > _______________________________________________
| > > 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
| https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2FZ35AkRhp2kCW4Q3MPeE%2BxY2bqaf%2FKm29ZfiqAKXxeo%3D%0A&m=ddVCC2gtph1oVCqUH9YT2m4FPFq30nYEcOq1BfSaqTI%3D%0A&s=bfdcab71e99a35eff0b6bd16ebe810dbe9b3eceba10de8a3f6963e77cc4e0015
|