Inline. ----- Original Message ----- | From: "Mohammad Banikazemi" <m...@us.ibm.com> | To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org> | Cc: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org> | Sent: Tuesday, December 17, 2013 11:42:53 AM | Subject: Re: [openstack-dev] [neutron] [policy] Policy-group relationship | | | | | Stephen Wong <s3w...@midokura.com> wrote on 12/15/2013 12:00:32 PM: | | > From: Stephen Wong <s3w...@midokura.com> | > To: "OpenStack Development Mailing List (not for usage questions)" | > <openstack-dev@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 | > <m...@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@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 | > | | _______________________________________________ | OpenStack-dev mailing list | OpenStack-dev@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 | _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
