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 dh...@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 hemanthrav...@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 rmo...@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@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] Bridging the 2-group gap in group policy
Thanks Kevin and others for the input here. We have put this on today's Group Policy IRC meeting agenda: https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy#July_31st.2C_2014 On Wed, Jul 30, 2014 at 11:59 PM, Kevin Benton blak...@gmail.com wrote: 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 dh...@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 hemanthrav...@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 rmo...@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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list
Re: [openstack-dev] [neutron][policy] Bridging the 2-group gap in group policy
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 blak...@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@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 dh...@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 hemanthrav...@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 rmo...@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
Re: [openstack-dev] [neutron][policy] Bridging the 2-group gap in group policy
I agree with Hemanth also - that this suggestion should be a different patch. And we should proceed with the current CLI patch. Thanks, - Stephen On Wed, Jul 30, 2014 at 11:13 AM, Hemanth Ravi hemanthrav...@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 rmo...@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@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] Bridging the 2-group gap in group policy
Ryan, So this is intended to associate a contract with a source EPG and a destination EPG – right? - Louis From: Mandeep Dhami [mailto:dh...@noironetworks.com] Sent: Wednesday, July 30, 2014 12:21 PM To: OpenStack Development Mailing List (not for usage questions) Cc: Subrahmanyam Ongole Subject: Re: [openstack-dev] [neutron][policy] Bridging the 2-group gap in group policy 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 hemanthrav...@gmail.commailto:hemanthrav...@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 rmo...@us.ibm.commailto:rmo...@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#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@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto: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] Bridging the 2-group gap in group policy
Yes Henry Fourie louis.fou...@huawei.com wrote on 07/31/2014 12:32:23 PM: From: Henry Fourie louis.fou...@huawei.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Cc: Subrahmanyam Ongole song...@oneconvergence.com Date: 07/31/2014 12:33 PM Subject: Re: [openstack-dev] [neutron][policy] Bridging the 2-group gap in group policy Ryan, So this is intended to associate a contract with a source EPG and a destination EPG – right? - Louis ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][policy] Bridging the 2-group gap in group policy
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 rmo...@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@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] Bridging the 2-group gap in group policy
Hi all, I support this API proposal. It is simple and conveys clear semantics. Thanks Ryan! Cathy From: Hemanth Ravi [mailto:hemanthrav...@gmail.com] Sent: Wednesday, July 30, 2014 11:13 AM To: OpenStack Development Mailing List (not for usage questions) Cc: Subrahmanyam Ongole Subject: Re: [openstack-dev] [neutron][policy] Bridging the 2-group gap in group policy 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 rmo...@us.ibm.commailto:rmo...@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#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@lists.openstack.orgmailto: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] Bridging the 2-group gap in group policy
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 hemanthrav...@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 rmo...@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@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
[openstack-dev] [neutron][policy] Bridging the 2-group gap in group policy
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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
