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