Re: [openstack-dev] [neutron][group-based-policy] Should we revisit the priority of group-based policy?
Great to see the discussions on the ML. Mohammad - Good summary. I would like to make few points 1) The current GP API is tuned towards person deploying the application as opposed to the networking person. This is probably a better way as one starts to think about self service infrastructure model and person deploying applications. We had debated about this on IRC and thought that policies/contract applied to the end point group would be easier abstraction. The complexity of networking is transformed to the implementation while still retaining the flexibility for network admin to provide additional policies. 2) I agree with mohammad that the feedback received for policy driven model was very positive. I heard in one of the BOF sessions a large operator commenting on this specifically in a very positive way. It would be sad to see this relegated to lesser priority. I am not saying that we should not address other issues in neutron but this should be addressed with equal priority. Especially when a lot of thought and PoC is already being done. 3) It was to good see consensus on the IRC today about the process particularly around code simplification, checkins and reviews as raised in the emails. thanks prasadv On Thu, May 22, 2014 at 9:10 PM, Mohammad Banikazemi m...@us.ibm.com wrote: Thanks to everyone who participated in the Group Policy meeting [1] earlier today. A lot of good discussion that hopefully will continue with participation from the larger community. I wanted to first make a comment about how the Group Policy work was received outside the Neutron community and then focus on finding a way for us to make progress. I think we had a really good feedback from the larger OpenStack community and I would say a wide support for addition of policy abstractions to Neutron. If the feedback we received at the summit in Hong Kong was mostly positive, in Atlanta the support was overwhelmingly positive in my opinion. I just wanted to make sure this does not get lost in our discussions. Needless to say, we will work on a path to have the Group Policy work included in Neutron in a way that keeps the quality of code in Neutron preserved. To rephrase what Armando said in the IRC meeting earlier today, we all share a common goal and that is to do what's right. I think it may be beneficial that for the moment and for the next few days as we try to find the best path forward, we forget about any particular cycle/milestone/priority and look for the best path forward and see where that leads us. To this end, the group policy team will be setting up a meeting with Armando (and others who are interested) to in particular discuss the possibility of making the code less tightly coupled with Neutron core. We will also consider how we can address Marun's and Mark's concerns by trying to have a simpler but functional set of patches that can be reviewed more effectively such that we can build on them in an iterative manner. Meanwhile, please do continue the discussion on the mailing list. Best, Mohammad [1] https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy [image: Inactive hide details for Armando M. ---05/22/2014 11:24:35 PM---On 22 May 2014 13:59, Mandeep Dhami dh...@noironetworks.com]Armando M. ---05/22/2014 11:24:35 PM---On 22 May 2014 13:59, Mandeep Dhami dh...@noironetworks.com wrote: From: Armando M. arma...@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org, Date: 05/22/2014 11:24 PM Subject: Re: [openstack-dev] [neutron][group-based-policy] Should we revisit the priority of group-based policy? -- On 22 May 2014 13:59, Mandeep Dhami dh...@noironetworks.com wrote: Maru's concerns are that: 1. It is large 2. It is complex And Armando's related concerns are: 3. Could dev/review cycles be better spent on refactoring 4. If refactored neutron was available, would a simpler option become more viable This is not what I meant to say, and if this was the message that came across I apologize for the confusion; let me rephrase: After looking (and relooking) at the initial patches proposed I started to question why the GP plugin functionality was so tightly integrated with the Neutron core functionality; even though I might guess the thinking process, I wonder if such tight coupling was the result of design decisions made without thoroughly considering alternative approaches. Without going too much into details during this email, I can see in the above mentioned patches that lots of plumbing code (like Nova and dhcp notifiers handling code) is put in place to make direct calls to core plugin methods: this spills implementation details across multiple parts of the project; it's fragile because it's prone to ripple effects due to lack of proper encapsulation: if a change is made in the plugin API or its implementation, the whole thing needs
Re: [openstack-dev] [neutron][group-based-policy] Should we revisit the priority of group-based policy?
continue the discussion on the mailing list. Best, Mohammad [1] https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy [image: Inactive hide details for Armando M. ---05/22/2014 11:24:35 PM---On 22 May 2014 13:59, Mandeep Dhami dh...@noironetworks.com]Armando M. ---05/22/2014 11:24:35 PM---On 22 May 2014 13:59, Mandeep Dhami dh...@noironetworks.com wrote: From: Armando M. arma...@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org, Date: 05/22/2014 11:24 PM Subject: Re: [openstack-dev] [neutron][group-based-policy] Should we revisit the priority of group-based policy? -- On 22 May 2014 13:59, Mandeep Dhami dh...@noironetworks.com wrote: Maru's concerns are that: 1. It is large 2. It is complex And Armando's related concerns are: 3. Could dev/review cycles be better spent on refactoring 4. If refactored neutron was available, would a simpler option become more viable This is not what I meant to say, and if this was the message that came across I apologize for the confusion; let me rephrase: After looking (and relooking) at the initial patches proposed I started to question why the GP plugin functionality was so tightly integrated with the Neutron core functionality; even though I might guess the thinking process, I wonder if such tight coupling was the result of design decisions made without thoroughly considering alternative approaches. Without going too much into details during this email, I can see in the above mentioned patches that lots of plumbing code (like Nova and dhcp notifiers handling code) is put in place to make direct calls to core plugin methods: this spills implementation details across multiple parts of the project; it's fragile because it's prone to ripple effects due to lack of proper encapsulation: if a change is made in the plugin API or its implementation, the whole thing needs to be looked at, end-to-end: this does not scale from a human perspective (probably only a handful of people can really say that they know the Neutron codebase inside-out), it is difficult to maintain, it is difficult to test, it is difficult to extend. etc etc. Instead, I was advocating for an approach where GP and Neutron Core integrate via (a well defined and stable) REST API, or similar (more abstracted) mechanisms; this has obvious benefits because the two become suddenly loosely coupled: a change done in the way Neutron deals with DHCP messages is not going to have any effect to how the GP plugin create resources. Also, any potential refactoring of the Neutron Core will not cause the GP team to take the burden of bringing the current implementation forward. This is why I was proposing that we talk about the introduction of integration hooks, should they (or lack thereof) have been the culprit of such an initial design approach. Please, take my comments as initial reviews to the above patches, if you will :) To be constructive, as a core reviewer who should suggest alternatives, I would invite the people reading this thread to have a look at [1] and [2]: these were introduced by RAX to their cut of Neutron, having in mind exactly what I have been saying: adding functionality with zero impact to existing code. If something along those lines can be achieved, then this would be very beneficial for the progress of the GP effort as it transitions and evolves into/within Neutron, IMO. Having said that, I am making these points without particular reference to the complexity of the GP model being proposed, or the approach being taken to introduce it to the tree. Even though I share some of Maru's points, good architecture and design principles in software development should be followed wherever possible and irrespective of the domain where such development occur. Many thanks, Armando [1] - https://github.com/roaet/wafflehaus [2] - https://github.com/roaet/wafflehaus.neutron Let me address them in that order. 1. Re: It is large Group policy has an ambitious goal - provide devop teams with policy based controls that are usable at scale and with automation (say a higher governance layer like Congress). The fact that meeting a large challenge requires more code is natural. We understand that challenge, and that is why we did a prototype (as PoC that was demonstrated on the summit). And based on that learning we are incrementally creating patches for building the group based policy. Just because a task is large, we as neutron can not shy away from building it. That will only drive people who need it out side neutron (as we are seeing with the frustration that the LBaaS team had because they have a requirement that is large as well). 2. Re: It is complex Complexity depends on the context. Our goal was to make the end-user's life simpler (and more automated). To achieve some
Re: [openstack-dev] [neutron][group-based-policy] Should we revisit the priority of group-based policy?
Mohammad Banikazemi wrote: in Atlanta the support was overwhelmingly positive in my opinion. I just wanted to make sure this does not get lost in our discussions. Absolutely. I hadn't been following the group policy discussions prior to the summit but I was very impressed with what I saw and heard. to in particular discuss the possibility of making the code less tightly coupled with Neutron core. +1 to making it less tightly coupled (although I haven't been inside the code to have an opinion on how tightly coupled it is now) Let's keep in mind OSI-like layers and well defined interfaces between them. Coming from a hardware networking background I find it very convenient to think in terms of ports, networks, subnets and routers. Those concepts should continue to be basic building blocks of software defined networks. The layer 4+ stuff should be added on top with clean interfaces that don't entangle functionality up and down the stack. Strict OSI layer compliance has never been a great success, but the general concept has been very useful for a long time All the most painful protocols for a network person to deal with are the ones like SIP where clean separation of layers was indiscriminately violated. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][group-based-policy] Should we revisit the priority of group-based policy?
Thanks Paul. Feedback like this, from actual users of neutron in large deployments, is the very reason why I feel so strongly that we need to keep this a high priority work item. Regards, Mandeep On Fri, May 23, 2014 at 9:28 AM, CARVER, PAUL pc2...@att.com wrote: Mohammad Banikazemi wrote: in Atlanta the support was overwhelmingly positive in my opinion. I just wanted to make sure this does not get lost in our discussions. Absolutely. I hadn’t been following the group policy discussions prior to the summit but I was very impressed with what I saw and heard. to in particular discuss the possibility of making the code less tightly coupled with Neutron core. +1 to making it less tightly coupled (although I haven’t been inside the code to have an opinion on how tightly coupled it is now) Let’s keep in mind OSI-like layers and well defined interfaces between them. Coming from a hardware networking background I find it very convenient to think in terms of ports, networks, subnets and routers. Those concepts should continue to be basic building blocks of software defined networks. The layer 4+ stuff should be added on top with clean interfaces that don’t entangle functionality up and down the stack. Strict OSI layer compliance has never been a great success, but the general concept has been very useful for a long time All the most painful protocols for a network person to deal with are the ones like SIP where clean separation of layers was indiscriminately violated. ___ 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][group-based-policy] Should we revisit the priority of group-based policy?
Paul good points, and I am very happy to read that your expectations are very closely aligned with the direction we have taken (in terms of decoupling of the group policy layer from the underlying building blocks). Thanks also Kyle for your earlier email. I believe the team has always been aligned on the work items you describe. So onward to Juno! ;-) On Fri, May 23, 2014 at 9:41 AM, Mandeep Dhami dh...@noironetworks.com wrote: Thanks Paul. Feedback like this, from actual users of neutron in large deployments, is the very reason why I feel so strongly that we need to keep this a high priority work item. Regards, Mandeep On Fri, May 23, 2014 at 9:28 AM, CARVER, PAUL pc2...@att.com wrote: Mohammad Banikazemi wrote: in Atlanta the support was overwhelmingly positive in my opinion. I just wanted to make sure this does not get lost in our discussions. Absolutely. I hadn’t been following the group policy discussions prior to the summit but I was very impressed with what I saw and heard. to in particular discuss the possibility of making the code less tightly coupled with Neutron core. +1 to making it less tightly coupled (although I haven’t been inside the code to have an opinion on how tightly coupled it is now) Let’s keep in mind OSI-like layers and well defined interfaces between them. Coming from a hardware networking background I find it very convenient to think in terms of ports, networks, subnets and routers. Those concepts should continue to be basic building blocks of software defined networks. The layer 4+ stuff should be added on top with clean interfaces that don’t entangle functionality up and down the stack. Strict OSI layer compliance has never been a great success, but the general concept has been very useful for a long time All the most painful protocols for a network person to deal with are the ones like SIP where clean separation of layers was indiscriminately violated. ___ 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][group-based-policy] Should we revisit the priority of group-based policy?
in Hong Kong was mostly positive, in Atlanta the support was overwhelmingly positive in my opinion. I just wanted to make sure this does not get lost in our discussions. Needless to say, we will work on a path to have the Group Policy work included in Neutron in a way that keeps the quality of code in Neutron preserved. To rephrase what Armando said in the IRC meeting earlier today, we all share a common goal and that is to do what's right. I think it may be beneficial that for the moment and for the next few days as we try to find the best path forward, we forget about any particular cycle/milestone/priority and look for the best path forward and see where that leads us. To this end, the group policy team will be setting up a meeting with Armando (and others who are interested) to in particular discuss the possibility of making the code less tightly coupled with Neutron core. We will also consider how we can address Marun's and Mark's concerns by trying to have a simpler but functional set of patches that can be reviewed more effectively such that we can build on them in an iterative manner. Meanwhile, please do continue the discussion on the mailing list. Best, Mohammad [1] https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy [image: Inactive hide details for Armando M. ---05/22/2014 11:24:35 PM---On 22 May 2014 13:59, Mandeep Dhami dh...@noironetworks.com]Armando M. ---05/22/2014 11:24:35 PM---On 22 May 2014 13:59, Mandeep Dhami dh...@noironetworks.com wrote: From: Armando M. arma...@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org, Date: 05/22/2014 11:24 PM Subject: Re: [openstack-dev] [neutron][group-based-policy] Should we revisit the priority of group-based policy? -- On 22 May 2014 13:59, Mandeep Dhami dh...@noironetworks.com wrote: Maru's concerns are that: 1. It is large 2. It is complex And Armando's related concerns are: 3. Could dev/review cycles be better spent on refactoring 4. If refactored neutron was available, would a simpler option become more viable This is not what I meant to say, and if this was the message that came across I apologize for the confusion; let me rephrase: After looking (and relooking) at the initial patches proposed I started to question why the GP plugin functionality was so tightly integrated with the Neutron core functionality; even though I might guess the thinking process, I wonder if such tight coupling was the result of design decisions made without thoroughly considering alternative approaches. Without going too much into details during this email, I can see in the above mentioned patches that lots of plumbing code (like Nova and dhcp notifiers handling code) is put in place to make direct calls to core plugin methods: this spills implementation details across multiple parts of the project; it's fragile because it's prone to ripple effects due to lack of proper encapsulation: if a change is made in the plugin API or its implementation, the whole thing needs to be looked at, end-to-end: this does not scale from a human perspective (probably only a handful of people can really say that they know the Neutron codebase inside-out), it is difficult to maintain, it is difficult to test, it is difficult to extend. etc etc. Instead, I was advocating for an approach where GP and Neutron Core integrate via (a well defined and stable) REST API, or similar (more abstracted) mechanisms; this has obvious benefits because the two become suddenly loosely coupled: a change done in the way Neutron deals with DHCP messages is not going to have any effect to how the GP plugin create resources. Also, any potential refactoring of the Neutron Core will not cause the GP team to take the burden of bringing the current implementation forward. This is why I was proposing that we talk about the introduction of integration hooks, should they (or lack thereof) have been the culprit of such an initial design approach. Please, take my comments as initial reviews to the above patches, if you will :) To be constructive, as a core reviewer who should suggest alternatives, I would invite the people reading this thread to have a look at [1] and [2]: these were introduced by RAX to their cut of Neutron, having in mind exactly what I have been saying: adding functionality with zero impact to existing code. If something along those lines can be achieved, then this would be very beneficial for the progress of the GP effort as it transitions and evolves into/within Neutron, IMO. Having said that, I am making these points without particular reference to the complexity of the GP model being proposed, or the approach being taken to introduce it to the tree. Even though I share some of Maru's points, good architecture and design principles in software development should be followed wherever possible
Re: [openstack-dev] [neutron][group-based-policy] Should we revisit the priority of group-based policy?
On 5/23/14, 12:46 AM, Mandeep Dhami wrote: Hi Armando: Those are good points. I will let Bob Kukura chime in on the specifics of how we intend to do that integration. But if what you see in the prototype/PoC was our final design for integration with Neutron core, I would be worried about that too. That specific part of the code (events/notifications for DHCP) was done in that way just for the prototype - to allow us to experiment with the part that was new and needed experimentation, the APIs and the model. That is the exact reason that we did not initially check the code to gerrit - so that we do not confuse the review process with the prototype process. But we were requested by other cores to check in even the prototype code as WIP patches to allow for review of the API parts. That can unfortunately create this very misunderstanding. For the review, I would recommend not the WIP patches, as they contain the prototype parts as well, but just the final patches that are not marked WIP. If you such issues in that part of the code, please DO raise that as that would be code that we intend to upstream. I believe Bob did discuss the specifics of this integration issue with you at the summit, but like I said it is best if he represents that side himself. Armando and Mandeep, Right, we do need a workable solution for the GBP driver to invoke neutron API operations, and this came up at the summit. We started out in the PoC directly calling the plugin, as is currently done when creating ports for agents. But this is not sufficient because the DHCP notifications, and I think the nova notifications, are needed for VM ports. We also really should be generating the other notifications, enforcing quotas, etc. for the neutron resources. We could just use python-neutronclient, but I think we'd prefer to avoid the overhead. The neutron project already depends on python-neutronclient for some tests, the debug facility, and the metaplugin, so in retrospect, we could have easily used it in the PoC. With the existing REST code, if we could find the neutron.api.v2.base.Controller class instance for each resource, we could simply call create(), update(), delete(), and show() on these. I didn't see an easy way to find these Controller instances, so I threw together some code similar to these Controller methods for the PoC. It probably wouldn't take too much work to have neutron.manager.NeutronManager provide access to the Controller classes if we want to go this route. The core refactoring effort may eventually provide a nice solution, but we can't wait for this. It seems we'll need to either use python-neutronclient or get access to the Controller classes in the meantime. Any thoughts on these? Any other ideas? Thanks, -Bob Regards, Mandeep ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][group-based-policy] Should we revisit the priority of group-based policy?
Hi Bob, The approach towards having the neutron.manager.NeutronManager provide access to the Controller classes seems like something worth exploring for the shorter term. Thanks, ~Sumit. On Fri, May 23, 2014 at 12:31 PM, Robert Kukura kuk...@noironetworks.com wrote: On 5/23/14, 12:46 AM, Mandeep Dhami wrote: Hi Armando: Those are good points. I will let Bob Kukura chime in on the specifics of how we intend to do that integration. But if what you see in the prototype/PoC was our final design for integration with Neutron core, I would be worried about that too. That specific part of the code (events/notifications for DHCP) was done in that way just for the prototype - to allow us to experiment with the part that was new and needed experimentation, the APIs and the model. That is the exact reason that we did not initially check the code to gerrit - so that we do not confuse the review process with the prototype process. But we were requested by other cores to check in even the prototype code as WIP patches to allow for review of the API parts. That can unfortunately create this very misunderstanding. For the review, I would recommend not the WIP patches, as they contain the prototype parts as well, but just the final patches that are not marked WIP. If you such issues in that part of the code, please DO raise that as that would be code that we intend to upstream. I believe Bob did discuss the specifics of this integration issue with you at the summit, but like I said it is best if he represents that side himself. Armando and Mandeep, Right, we do need a workable solution for the GBP driver to invoke neutron API operations, and this came up at the summit. We started out in the PoC directly calling the plugin, as is currently done when creating ports for agents. But this is not sufficient because the DHCP notifications, and I think the nova notifications, are needed for VM ports. We also really should be generating the other notifications, enforcing quotas, etc. for the neutron resources. We could just use python-neutronclient, but I think we'd prefer to avoid the overhead. The neutron project already depends on python-neutronclient for some tests, the debug facility, and the metaplugin, so in retrospect, we could have easily used it in the PoC. With the existing REST code, if we could find the neutron.api.v2.base.Controller class instance for each resource, we could simply call create(), update(), delete(), and show() on these. I didn't see an easy way to find these Controller instances, so I threw together some code similar to these Controller methods for the PoC. It probably wouldn't take too much work to have neutron.manager.NeutronManager provide access to the Controller classes if we want to go this route. The core refactoring effort may eventually provide a nice solution, but we can't wait for this. It seems we'll need to either use python-neutronclient or get access to the Controller classes in the meantime. Any thoughts on these? Any other ideas? Thanks, -Bob Regards, Mandeep ___ 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][group-based-policy] Should we revisit the priority of group-based policy?
On 23 May 2014 12:31, Robert Kukura kuk...@noironetworks.com wrote: On 5/23/14, 12:46 AM, Mandeep Dhami wrote: Hi Armando: Those are good points. I will let Bob Kukura chime in on the specifics of how we intend to do that integration. But if what you see in the prototype/PoC was our final design for integration with Neutron core, I would be worried about that too. That specific part of the code (events/notifications for DHCP) was done in that way just for the prototype - to allow us to experiment with the part that was new and needed experimentation, the APIs and the model. That is the exact reason that we did not initially check the code to gerrit - so that we do not confuse the review process with the prototype process. But we were requested by other cores to check in even the prototype code as WIP patches to allow for review of the API parts. That can unfortunately create this very misunderstanding. For the review, I would recommend not the WIP patches, as they contain the prototype parts as well, but just the final patches that are not marked WIP. If you such issues in that part of the code, please DO raise that as that would be code that we intend to upstream. I believe Bob did discuss the specifics of this integration issue with you at the summit, but like I said it is best if he represents that side himself. Armando and Mandeep, Right, we do need a workable solution for the GBP driver to invoke neutron API operations, and this came up at the summit. We started out in the PoC directly calling the plugin, as is currently done when creating ports for agents. But this is not sufficient because the DHCP notifications, and I think the nova notifications, are needed for VM ports. We also really should be generating the other notifications, enforcing quotas, etc. for the neutron resources. I am at loss here: if you say that you couldn't fit at the plugin level, that is because it is the wrong level!! Sitting above it and redo all the glue code around it to add DHCP notifications etc continues the bad practice within the Neutron codebase where there is not a good separation of concerns: for instance everything is cobbled together like the DB and plugin logic. I appreciate that some design decisions have been made in the past, but there's no good reason for a nice new feature like GP to continue this bad practice; this is why I feel strongly about the current approach being taken. We could just use python-neutronclient, but I think we'd prefer to avoid the overhead. The neutron project already depends on python-neutronclient for some tests, the debug facility, and the metaplugin, so in retrospect, we could have easily used it in the PoC. I am not sure I understand what overhead you mean here. Could you clarify? Actually looking at the code, I see a mind boggling set of interactions going back and forth between the GP plugin, the policy driver manager, the mapping driver and the core plugin: they are all entangled together. For instance, when creating an endpoint the GP plugin ends up calling the mapping driver that in turns ends up calls the GP plugin itself! If this is not overhead I don't know what is! The way the code has been structured makes it very difficult to read, let alone maintain and extend with other policy mappers. The ML2-like nature of the approach taken might work well in the context of core plugin, mechanisms drivers etc, but I would argue that it poorly applies to the context of GP. With the existing REST code, if we could find the neutron.api.v2.base.Controller class instance for each resource, we could simply call create(), update(), delete(), and show() on these. I didn't see an easy way to find these Controller instances, so I threw together some code similar to these Controller methods for the PoC. It probably wouldn't take too much work to have neutron.manager.NeutronManager provide access to the Controller classes if we want to go this route. The core refactoring effort may eventually provide a nice solution, but we can't wait for this. It seems we'll need to either use python-neutronclient or get access to the Controller classes in the meantime. Any thoughts on these? Any other ideas? I am still not sure why do you even need to go all the way down to the Controller class. After all it's almost like GP could be a service in its own right that makes use of Neutron to map the application centric abstractions on top of the networking constructs; this can happen via the REST interface. I don't think there is a dependency on the core refactoring here: the two can progress separately, so long as we break the tie, from an implementation perspective, that GP and Core plugins need to leave in the same address space. Am I missing something? Because I still cannot justify why things have been coded the way they have. Thanks, Armando Thanks, -Bob Regards, Mandeep ___
[openstack-dev] [neutron][group-based-policy] Should we revisit the priority of group-based policy?
At the summit session last week for group-based policy, there were many concerns voiced about the approach being undertaken. I think those concerns deserve a wider audience, and I'm going to highlight some of them here. The primary concern seemed to be related to the complexity of the approach implemented for the POC. A number of session participants voiced concern that the simpler approach documented in the original proposal [1] (described in the section titled 'Policies applied between groups') had not been implemented in addition to or instead of what appeared in the POC (described in the section titled 'Policies applied as a group API'). The simpler approach was considered by those participants as having the advantage of clarity and immediate usefulness, whereas the complex approach was deemed hard to understand and without immediate utility. A secondary but no less important concern is related to the impact on Neutron of the approach implemented in the POC. The POC was developed monolithically, without oversight through gerrit, and the resulting patches were excessive in size (~4700 [2] and ~1500 [3] lines). Such large patches are effectively impossible to review. Even broken down into reviewable chunks, though, it does not seem realistic to target juno-1 for merging this kind of complexity. The impact on stability could be considerable, and it is questionable whether the necessary review effort should be devoted to fast-tracking group-based policy at all, let alone an approach that is considered by many to be unnecessarily complicated. The blueprint for group policy [4] is currently listed as a 'High' priority. With the above concerns in mind, does it make sense to continue prioritizing an effort that at present would seem to require considerably more resources than the benefit it appears to promise? Maru 1: https://etherpad.openstack.org/p/group-based-policy 2: https://review.openstack.org/93853 3: https://review.openstack.org/93935 4: https://blueprints.launchpad.net/neutron/+spec/group-based-policy-abstraction ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][group-based-policy] Should we revisit the priority of group-based policy?
On May 22, 2014, at 11:03 AM, Maru Newby ma...@redhat.com wrote: At the summit session last week for group-based policy, there were many concerns voiced about the approach being undertaken. I think those concerns deserve a wider audience, and I'm going to highlight some of them here. The primary concern seemed to be related to the complexity of the approach implemented for the POC. A number of session participants voiced concern that the simpler approach documented in the original proposal [1] (described in the section titled 'Policies applied between groups') had not been implemented in addition to or instead of what appeared in the POC (described in the section titled 'Policies applied as a group API'). The simpler approach was considered by those participants as having the advantage of clarity and immediate usefulness, whereas the complex approach was deemed hard to understand and without immediate utility. A secondary but no less important concern is related to the impact on Neutron of the approach implemented in the POC. The POC was developed monolithically, without oversight through gerrit, and the resulting patches were excessive in size (~4700 [2] and ~1500 [3] lines). Such large patches are effectively impossible to review. Even broken down into reviewable chunks, though, it does not seem realistic to target juno-1 for merging this kind of complexity. The impact on stability could be considerable, and it is questionable whether the necessary review effort should be devoted to fast-tracking group-based policy at all, let alone an approach that is considered by many to be unnecessarily complicated. The blueprint for group policy [4] is currently listed as a 'High' priority. With the above concerns in mind, does it make sense to continue prioritizing an effort that at present would seem to require considerably more resources than the benefit it appears to promise? Maru 1: https://etherpad.openstack.org/p/group-based-policy Apologies, this link is to the summit session etherpad. The link to the original proposal is: https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIrupCD9E/edit 2: https://review.openstack.org/93853 3: https://review.openstack.org/93935 4: https://blueprints.launchpad.net/neutron/+spec/group-based-policy-abstraction ___ 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][group-based-policy] Should we revisit the priority of group-based policy?
I would second Maru's concerns, and I would also like to add the following: We need to acknowledge the fact that there are certain architectural aspects of Neutron as a project that need to be addressed; at the summit we talked about the core refactoring, a task oriented API, etc. To me these items have been neglected far too much over the past and would need a higher priority and a lot more attention during the Juno cycle. Being stretched as we are I wonder if dev/review cycles wouldn't be better spent devoting more time to these efforts rather than GP. That said, I appreciate that GP is important and needs to move forward, but at the same time I am thinking that there must be a better way for addressing it and yet relieve some of the pressure that GP complexity imposes to the Neutron team. One aspect it was discussed at the summit was that the type of approach shown in [2] and [3] below, was chosen because of lack of proper integration hooks...so I am advocating: let's talk about those first before ruling them out in favor of a monolithic approach that seems to violate some engineering principles, like modularity and loose decoupling of system components. I think we didn't have enough time during the summit to iron out some of the concerns voiced here, and it seems like the IRC meeting for Group Policy would not be the right venue to try and establish a common ground among the people driving this effort and the rest of the core team. Shall we try and have an ad-hoc meeting and an ad-hoc agenda to find a consensus? Many thanks, Armando On 22 May 2014 11:38, Maru Newby ma...@redhat.com wrote: On May 22, 2014, at 11:03 AM, Maru Newby ma...@redhat.com wrote: At the summit session last week for group-based policy, there were many concerns voiced about the approach being undertaken. I think those concerns deserve a wider audience, and I'm going to highlight some of them here. The primary concern seemed to be related to the complexity of the approach implemented for the POC. A number of session participants voiced concern that the simpler approach documented in the original proposal [1] (described in the section titled 'Policies applied between groups') had not been implemented in addition to or instead of what appeared in the POC (described in the section titled 'Policies applied as a group API'). The simpler approach was considered by those participants as having the advantage of clarity and immediate usefulness, whereas the complex approach was deemed hard to understand and without immediate utility. A secondary but no less important concern is related to the impact on Neutron of the approach implemented in the POC. The POC was developed monolithically, without oversight through gerrit, and the resulting patches were excessive in size (~4700 [2] and ~1500 [3] lines). Such large patches are effectively impossible to review. Even broken down into reviewable chunks, though, it does not seem realistic to target juno-1 for merging this kind of complexity. The impact on stability could be considerable, and it is questionable whether the necessary review effort should be devoted to fast-tracking group-based policy at all, let alone an approach that is considered by many to be unnecessarily complicated. The blueprint for group policy [4] is currently listed as a 'High' priority. With the above concerns in mind, does it make sense to continue prioritizing an effort that at present would seem to require considerably more resources than the benefit it appears to promise? Maru 1: https://etherpad.openstack.org/p/group-based-policy Apologies, this link is to the summit session etherpad. The link to the original proposal is: https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIrupCD9E/edit 2: https://review.openstack.org/93853 3: https://review.openstack.org/93935 4: https://blueprints.launchpad.net/neutron/+spec/group-based-policy-abstraction ___ 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][group-based-policy] Should we revisit the priority of group-based policy?
Maru's concerns are that: 1. It is large 2. It is complex And Armando's related concerns are: 3. Could dev/review cycles be better spent on refactoring 4. If refactored neutron was available, would a simpler option become more viable Let me address them in that order. 1. Re: It is large Group policy has an ambitious goal - provide devop teams with policy based controls that are usable at scale and with automation (say a higher governance layer like Congress). The fact that meeting a large challenge requires more code is natural. We understand that challenge, and that is why we did a prototype (as PoC that was demonstrated on the summit). And based on that learning we are incrementally creating patches for building the group based policy. Just because a task is large, we as neutron can not shy away from building it. That will only drive people who need it out side neutron (as we are seeing with the frustration that the LBaaS team had because they have a requirement that is large as well). 2. Re: It is complex Complexity depends on the context. Our goal was to make the end-user's life simpler (and more automated). To achieve some of that simplicity, we required a little more complexity in the implementation. We decide to make that arbitrage - a little higher complexity in implementation to allow for simpler usage. But we were careful and did not want to impose that complexity on every use case - hence a lot of that is optional (and exercised only if the use case needs it). Unfortunately the model, has to model all of it so as it not add complexity later in upgrade and backward compatibility issues. We choose to do architecture upfront, and then implement it incrementally. The team came up with the model currently in model based on that review and evaluation all the proposals in the document that you refer. It is easy to make general comments, but unless you participate in the process and sign up to writing the code, those comments are not going to help with solving the original problem. And this _is_ open-source. If you disagree, please write code and the community can decide for itself as to what model is actually simple to use for them. Curtailing efforts from other developers just because their engineering trade-offs are different from what you believe your use-case needs is not why we like open source. We enjoy the mode where different developers try different things, we experiment, and the software evolves to what the user demands. Or maybe, multiple models live in harmony. Let the users decide that. 3. Re: Could dev/review cycles be better spent on refactoring I think that most people agree that policy control is an important feature that fundamentally improves neutron (by solving the automation and scale issues). In a large project, multiple sub-projects can, and for a healthy project should, work in parallel. I understand that the neutron core team is stretched. But we still need to be able to balance the needs of today (paying off the technical debt/existing-issues by doing refactoring) with needs of tomorrow (new features like GP and LBaaS). GP effort was started in Havana, and now we are trying to get this in Juno. I think that is reasonable and a long enough cycle for a high priority project to be able to get some core attention. Again I refer to LBaaS experience, as they struggled with very similar issues. 4. Re: If refactored neutron was available, would a simpler option become more viable We would love to be able to answer that question. We have been trying to understand the refactoring work to understand this (see another ML thread) and we are open to understanding your position on that. We will call the ad-hoc meeting that you suggested and we would like to understand the refactoring work that might be reused for simpler policy implementation. At the same time, we would like to build on what is available today, and when the required refactored neutron becomes available (say Juno or K-release), we are more than happy to adapt to it at that time. Serializing all development around an effort that is still in inception phase is not a good solution. We are looking forward to participating in the core refactoring work, and based on the final spec that come up with, we would love to be able to eventually make the policy implementation simpler. Regards, Mandeep On Thu, May 22, 2014 at 11:44 AM, Armando M. arma...@gmail.com wrote: I would second Maru's concerns, and I would also like to add the following: We need to acknowledge the fact that there are certain architectural aspects of Neutron as a project that need to be addressed; at the summit we talked about the core refactoring, a task oriented API, etc. To me these items have been neglected far too much over the past and would need a higher priority and a lot more attention during the Juno cycle. Being stretched as we are I wonder if dev/review cycles wouldn't be better spent devoting more time to these efforts rather
Re: [openstack-dev] [neutron][group-based-policy] Should we revisit the priority of group-based policy?
On May 22, 2014, at 1:59 PM, Mandeep Dhami dh...@noironetworks.com wrote: Maru's concerns are that: 1. It is large 2. It is complex As per the discussion in the irc meeting today, I hope it is clear now that eventual size and complexity are not real issue. Rather, I am concerned at how we get there. I keep talking about 'iterating in the open', and want to make it clear what I mean by this. It involves proposing a reviewable patch to openstack gerrit, working with reviewers to get the patch merged, and then incorporating their feedback into the overall design to drive the implementation of future patches. 'Iterating in the open' does not imply working outside of gerrit to create a monolithic codebase that needs to be manually decomposed into reviewable chunks at the end. I understand that this may be an effective way to create a POC, but it is not an effective way to produce code that can be merged into Neutron. Core reviewers have a mandate to ensure the quality of every patch, and their feedback is likely to have an impact on subsequent implementation. And Armando's related concerns are: 3. Could dev/review cycles be better spent on refactoring 4. If refactored neutron was available, would a simpler option become more viable Let me address them in that order. 1. Re: It is large Group policy has an ambitious goal - provide devop teams with policy based controls that are usable at scale and with automation (say a higher governance layer like Congress). The fact that meeting a large challenge requires more code is natural. We understand that challenge, and that is why we did a prototype (as PoC that was demonstrated on the summit). And based on that learning we are incrementally creating patches for building the group based policy. Just because a task is large, we as neutron can not shy away from building it. That will only drive people who need it out side neutron (as we are seeing with the frustration that the LBaaS team had because they have a requirement that is large as well). Again, the amount of code is not the problem. How code is introduced into the tree, and how the design is socialized (both with developers and users), _is_ of critical importance. Neutron is not alone in requiring an 'iterate in the open' approach - it is a characteristic common to many open source projects. 2. Re: It is complex Complexity depends on the context. Our goal was to make the end-user's life simpler (and more automated). To achieve some of that simplicity, we required a little more complexity in the implementation. We decide to make that arbitrage - a little higher complexity in implementation to allow for simpler usage. But we were careful and did not want to impose that complexity on every use case - hence a lot of that is optional (and exercised only if the use case needs it). Unfortunately the model, has to model all of it so as it not add complexity later in upgrade and backward compatibility issues. We choose to do architecture upfront, and then implement it incrementally. Doing upfront architecture is fine, so long as the architecture also evolves in response to feedback from the review process in gerrit. Similarly, incremental implementation is not enough - it needs to happen in gerrit. And to be clear, the tool is not the critical factor. When I say gerrit, I mean that each patch needs to receive core reviewer attention and that subsequent patches incorporate their feedback. The team came up with the model currently in model based on that review and evaluation all the proposals in the document that you refer. It is easy to make general comments, but unless you participate in the process and sign up to writing the code, those comments are not going to help with solving the original problem. And this _is_ open-source. If you disagree, please write code and the community can decide for itself as to what model is actually simple to use for them. Curtailing efforts from other developers just because their engineering trade-offs are different from what you believe your use-case needs is not why we like open source. We enjoy the mode where different developers try different things, we experiment, and the software evolves to what the user demands. Or maybe, multiple models live in harmony. Let the users decide that. You are correct in saying that it is not my job to decide what you or other developers do. It is, however, my role as a Neutron core reviewer to ensure that we make good use of the resources available to us to meet the project's commitments. If I believe that the approach chosen to implement a given Neutron feature has the potential to starve other priorities of resources, then I have a responsibility to voice that concern and push back. You're free to implement whatever you want outside of the tree, but participating in the Neutron community means accepting the norms
Re: [openstack-dev] [neutron][group-based-policy] Should we revisit the priority of group-based policy?
On 05/22/2014 07:03 PM, Maru Newby wrote: On May 22, 2014, at 1:59 PM, Mandeep Dhami dh...@noironetworks.com wrote: Maru's concerns are that: 1. It is large 2. It is complex As per the discussion in the irc meeting today, I hope it is clear now that eventual size and complexity are not real issue. Rather, I am concerned at how we get there. I keep talking about 'iterating in the open', and want to make it clear what I mean by this. It involves proposing a reviewable patch to openstack gerrit, working with reviewers to get the patch merged, and then incorporating their feedback into the overall design to drive the implementation of future patches. 'Iterating in the open' does not imply working outside of gerrit to create a monolithic codebase that needs to be manually decomposed into reviewable chunks at the end. I understand that this may be an effective way to create a POC, but it is not an effective way to produce code that can be merged into Neutron. Core reviewers have a mandate to ensure the quality of every patch, and their feedback is likely to have an impact on subsequent implementation. We talked about Stacked policy for RBAC at the Summit. I wonder if we are looking at two sides of the same problem. For Keystone, teh pieces identified so far are: associating policy with a server or endpoint, the auth_token middleware fetching it, and then the ability of a domain or project to define its own sub-policy. At the API level, I was wondering about delegation, which is really what policy is about: instead of delegating a role, can I delegate the ability to perform just a single operations. But even that is not fine grained enough. Really, we need policy on objects. For example, role assignments: I want to be able to delegate to a group admin the ability to assign users to his group. That means he can assign the role Member to users in his group, but no other role. The mechanisms to implement this are going to be common, I think across all of the services. I think we are getting into SELinux land. And Armando's related concerns are: 3. Could dev/review cycles be better spent on refactoring 4. If refactored neutron was available, would a simpler option become more viable Let me address them in that order. 1. Re: It is large Group policy has an ambitious goal - provide devop teams with policy based controls that are usable at scale and with automation (say a higher governance layer like Congress). The fact that meeting a large challenge requires more code is natural. We understand that challenge, and that is why we did a prototype (as PoC that was demonstrated on the summit). And based on that learning we are incrementally creating patches for building the group based policy. Just because a task is large, we as neutron can not shy away from building it. That will only drive people who need it out side neutron (as we are seeing with the frustration that the LBaaS team had because they have a requirement that is large as well). Again, the amount of code is not the problem. How code is introduced into the tree, and how the design is socialized (both with developers and users), _is_ of critical importance. Neutron is not alone in requiring an 'iterate in the open' approach - it is a characteristic common to many open source projects. 2. Re: It is complex Complexity depends on the context. Our goal was to make the end-user's life simpler (and more automated). To achieve some of that simplicity, we required a little more complexity in the implementation. We decide to make that arbitrage - a little higher complexity in implementation to allow for simpler usage. But we were careful and did not want to impose that complexity on every use case - hence a lot of that is optional (and exercised only if the use case needs it). Unfortunately the model, has to model all of it so as it not add complexity later in upgrade and backward compatibility issues. We choose to do architecture upfront, and then implement it incrementally. Doing upfront architecture is fine, so long as the architecture also evolves in response to feedback from the review process in gerrit. Similarly, incremental implementation is not enough - it needs to happen in gerrit. And to be clear, the tool is not the critical factor. When I say gerrit, I mean that each patch needs to receive core reviewer attention and that subsequent patches incorporate their feedback. The team came up with the model currently in model based on that review and evaluation all the proposals in the document that you refer. It is easy to make general comments, but unless you participate in the process and sign up to writing the code, those comments are not going to help with solving the original problem. And this _is_ open-source. If you disagree, please write code and the community can decide for itself as to what model is actually simple to use for them. Curtailing efforts from
Re: [openstack-dev] [neutron][group-based-policy] Should we revisit the priority of group-based policy?
each patch needs to receive core reviewer attention and that subsequent patches incorporate their feedback. At least two core neutron members were involved in creating the PoC, and at least two more cores were involved in reviews at various times. In addition to them, senior developers from at least seven networking companies were involved in developing this code. I concede that this code was on github for a few weeks, as that made the prototyping faster and allowed us to fail faster, but it was open and reviewed with the team above (and with the cores in that team). Based on our learning from that prototype activity, and feedback of those cores, we are upstreaming the improved production code to gerrit. All that involvement from the neutron core reviewers was critical in keeping the larger PoC team above focused on neutron norms and expectations from design and code. On Thu, May 22, 2014 at 4:03 PM, Maru Newby ma...@redhat.com wrote: On May 22, 2014, at 1:59 PM, Mandeep Dhami dh...@noironetworks.com wrote: Maru's concerns are that: 1. It is large 2. It is complex As per the discussion in the irc meeting today, I hope it is clear now that eventual size and complexity are not real issue. Rather, I am concerned at how we get there. I keep talking about 'iterating in the open', and want to make it clear what I mean by this. It involves proposing a reviewable patch to openstack gerrit, working with reviewers to get the patch merged, and then incorporating their feedback into the overall design to drive the implementation of future patches. 'Iterating in the open' does not imply working outside of gerrit to create a monolithic codebase that needs to be manually decomposed into reviewable chunks at the end. I understand that this may be an effective way to create a POC, but it is not an effective way to produce code that can be merged into Neutron. Core reviewers have a mandate to ensure the quality of every patch, and their feedback is likely to have an impact on subsequent implementation. And Armando's related concerns are: 3. Could dev/review cycles be better spent on refactoring 4. If refactored neutron was available, would a simpler option become more viable Let me address them in that order. 1. Re: It is large Group policy has an ambitious goal - provide devop teams with policy based controls that are usable at scale and with automation (say a higher governance layer like Congress). The fact that meeting a large challenge requires more code is natural. We understand that challenge, and that is why we did a prototype (as PoC that was demonstrated on the summit). And based on that learning we are incrementally creating patches for building the group based policy. Just because a task is large, we as neutron can not shy away from building it. That will only drive people who need it out side neutron (as we are seeing with the frustration that the LBaaS team had because they have a requirement that is large as well). Again, the amount of code is not the problem. How code is introduced into the tree, and how the design is socialized (both with developers and users), _is_ of critical importance. Neutron is not alone in requiring an 'iterate in the open' approach - it is a characteristic common to many open source projects. 2. Re: It is complex Complexity depends on the context. Our goal was to make the end-user's life simpler (and more automated). To achieve some of that simplicity, we required a little more complexity in the implementation. We decide to make that arbitrage - a little higher complexity in implementation to allow for simpler usage. But we were careful and did not want to impose that complexity on every use case - hence a lot of that is optional (and exercised only if the use case needs it). Unfortunately the model, has to model all of it so as it not add complexity later in upgrade and backward compatibility issues. We choose to do architecture upfront, and then implement it incrementally. Doing upfront architecture is fine, so long as the architecture also evolves in response to feedback from the review process in gerrit. Similarly, incremental implementation is not enough - it needs to happen in gerrit. And to be clear, the tool is not the critical factor. When I say gerrit, I mean that each patch needs to receive core reviewer attention and that subsequent patches incorporate their feedback. The team came up with the model currently in model based on that review and evaluation all the proposals in the document that you refer. It is easy to make general comments, but unless you participate in the process and sign up to writing the code, those comments are not going to help with solving the original problem. And this _is_ open-source. If you disagree, please write code and the community can decide for itself as to what model is actually simple to use for them. Curtailing efforts
Re: [openstack-dev] [neutron][group-based-policy] Should we revisit the priority of group-based policy?
On May 22, 2014, at 4:35 PM, Mandeep Dhami dh...@noironetworks.com wrote: each patch needs to receive core reviewer attention and that subsequent patches incorporate their feedback. At least two core neutron members were involved in creating the PoC, and at least two more cores were involved in reviews at various times. In addition to them, senior developers from at least seven networking companies were involved in developing this code. I concede that this code was on github for a few weeks, as that made the prototyping faster and allowed us to fail faster, but it was open and reviewed with the team above (and with the cores in that team). Based on our learning from that prototype activity, and feedback of those cores, we are upstreaming the improved production code to gerrit. All that involvement from the neutron core reviewers was critical in keeping the larger PoC team above focused on neutron norms and expectations from design and code. The feedback from reviewers needs to be provided on openstack infrastructure rather than outside it so that it is both visible to all reviewers (not just those directly involved) and that an enduring history of the process is retained. These requirements were not met in working in github on the POC, regardless of your protestations of how 'open' that work was and of who was involved. This isn't to suggest that out-of-tree prototyping isn't useful - of course it is. But I think it important to recognize that out-of-tree development is unlikely to be an effective way to develop code that can be easily merged to Neutron, and that the project can ill-afford the additional review cost it is likely to impose. As such, and as was agreed to in the irc meeting this morning, the way forward is to recognize that the POC is best considered a prototype useful in informing efforts to iterate in the open. m. On Thu, May 22, 2014 at 4:03 PM, Maru Newby ma...@redhat.com wrote: On May 22, 2014, at 1:59 PM, Mandeep Dhami dh...@noironetworks.com wrote: Maru's concerns are that: 1. It is large 2. It is complex As per the discussion in the irc meeting today, I hope it is clear now that eventual size and complexity are not real issue. Rather, I am concerned at how we get there. I keep talking about 'iterating in the open', and want to make it clear what I mean by this. It involves proposing a reviewable patch to openstack gerrit, working with reviewers to get the patch merged, and then incorporating their feedback into the overall design to drive the implementation of future patches. 'Iterating in the open' does not imply working outside of gerrit to create a monolithic codebase that needs to be manually decomposed into reviewable chunks at the end. I understand that this may be an effective way to create a POC, but it is not an effective way to produce code that can be merged into Neutron. Core reviewers have a mandate to ensure the quality of every patch, and their feedback is likely to have an impact on subsequent implementation. And Armando's related concerns are: 3. Could dev/review cycles be better spent on refactoring 4. If refactored neutron was available, would a simpler option become more viable Let me address them in that order. 1. Re: It is large Group policy has an ambitious goal - provide devop teams with policy based controls that are usable at scale and with automation (say a higher governance layer like Congress). The fact that meeting a large challenge requires more code is natural. We understand that challenge, and that is why we did a prototype (as PoC that was demonstrated on the summit). And based on that learning we are incrementally creating patches for building the group based policy. Just because a task is large, we as neutron can not shy away from building it. That will only drive people who need it out side neutron (as we are seeing with the frustration that the LBaaS team had because they have a requirement that is large as well). Again, the amount of code is not the problem. How code is introduced into the tree, and how the design is socialized (both with developers and users), _is_ of critical importance. Neutron is not alone in requiring an 'iterate in the open' approach - it is a characteristic common to many open source projects. 2. Re: It is complex Complexity depends on the context. Our goal was to make the end-user's life simpler (and more automated). To achieve some of that simplicity, we required a little more complexity in the implementation. We decide to make that arbitrage - a little higher complexity in implementation to allow for simpler usage. But we were careful and did not want to impose that complexity on every use case - hence a lot of that is optional (and exercised only if the use case needs it). Unfortunately the model, has to model all of it
Re: [openstack-dev] [neutron][group-based-policy] Should we revisit the priority of group-based policy?
OK. On Thu, May 22, 2014 at 5:13 PM, Maru Newby ma...@redhat.com wrote: On May 22, 2014, at 4:35 PM, Mandeep Dhami dh...@noironetworks.com wrote: each patch needs to receive core reviewer attention and that subsequent patches incorporate their feedback. At least two core neutron members were involved in creating the PoC, and at least two more cores were involved in reviews at various times. In addition to them, senior developers from at least seven networking companies were involved in developing this code. I concede that this code was on github for a few weeks, as that made the prototyping faster and allowed us to fail faster, but it was open and reviewed with the team above (and with the cores in that team). Based on our learning from that prototype activity, and feedback of those cores, we are upstreaming the improved production code to gerrit. All that involvement from the neutron core reviewers was critical in keeping the larger PoC team above focused on neutron norms and expectations from design and code. The feedback from reviewers needs to be provided on openstack infrastructure rather than outside it so that it is both visible to all reviewers (not just those directly involved) and that an enduring history of the process is retained. These requirements were not met in working in github on the POC, regardless of your protestations of how 'open' that work was and of who was involved. This isn't to suggest that out-of-tree prototyping isn't useful - of course it is. But I think it important to recognize that out-of-tree development is unlikely to be an effective way to develop code that can be easily merged to Neutron, and that the project can ill-afford the additional review cost it is likely to impose. As such, and as was agreed to in the irc meeting this morning, the way forward is to recognize that the POC is best considered a prototype useful in informing efforts to iterate in the open. m. On Thu, May 22, 2014 at 4:03 PM, Maru Newby ma...@redhat.com wrote: On May 22, 2014, at 1:59 PM, Mandeep Dhami dh...@noironetworks.com wrote: Maru's concerns are that: 1. It is large 2. It is complex As per the discussion in the irc meeting today, I hope it is clear now that eventual size and complexity are not real issue. Rather, I am concerned at how we get there. I keep talking about 'iterating in the open', and want to make it clear what I mean by this. It involves proposing a reviewable patch to openstack gerrit, working with reviewers to get the patch merged, and then incorporating their feedback into the overall design to drive the implementation of future patches. 'Iterating in the open' does not imply working outside of gerrit to create a monolithic codebase that needs to be manually decomposed into reviewable chunks at the end. I understand that this may be an effective way to create a POC, but it is not an effective way to produce code that can be merged into Neutron. Core reviewers have a mandate to ensure the quality of every patch, and their feedback is likely to have an impact on subsequent implementation. And Armando's related concerns are: 3. Could dev/review cycles be better spent on refactoring 4. If refactored neutron was available, would a simpler option become more viable Let me address them in that order. 1. Re: It is large Group policy has an ambitious goal - provide devop teams with policy based controls that are usable at scale and with automation (say a higher governance layer like Congress). The fact that meeting a large challenge requires more code is natural. We understand that challenge, and that is why we did a prototype (as PoC that was demonstrated on the summit). And based on that learning we are incrementally creating patches for building the group based policy. Just because a task is large, we as neutron can not shy away from building it. That will only drive people who need it out side neutron (as we are seeing with the frustration that the LBaaS team had because they have a requirement that is large as well). Again, the amount of code is not the problem. How code is introduced into the tree, and how the design is socialized (both with developers and users), _is_ of critical importance. Neutron is not alone in requiring an 'iterate in the open' approach - it is a characteristic common to many open source projects. 2. Re: It is complex Complexity depends on the context. Our goal was to make the end-user's life simpler (and more automated). To achieve some of that simplicity, we required a little more complexity in the implementation. We decide to make that arbitrage - a little higher complexity in implementation to allow for simpler usage. But we were careful and did not want to impose that complexity on every use case - hence a lot of that is optional (and exercised only if the use case needs it).
Re: [openstack-dev] [neutron][group-based-policy] Should we revisit the priority of group-based policy?
On 22 May 2014 13:59, Mandeep Dhami dh...@noironetworks.com wrote: Maru's concerns are that: 1. It is large 2. It is complex And Armando's related concerns are: 3. Could dev/review cycles be better spent on refactoring 4. If refactored neutron was available, would a simpler option become more viable This is not what I meant to say, and if this was the message that came across I apologize for the confusion; let me rephrase: After looking (and relooking) at the initial patches proposed I started to question why the GP plugin functionality was so tightly integrated with the Neutron core functionality; even though I might guess the thinking process, I wonder if such tight coupling was the result of design decisions made without thoroughly considering alternative approaches. Without going too much into details during this email, I can see in the above mentioned patches that lots of plumbing code (like Nova and dhcp notifiers handling code) is put in place to make direct calls to core plugin methods: this spills implementation details across multiple parts of the project; it's fragile because it's prone to ripple effects due to lack of proper encapsulation: if a change is made in the plugin API or its implementation, the whole thing needs to be looked at, end-to-end: this does not scale from a human perspective (probably only a handful of people can really say that they know the Neutron codebase inside-out), it is difficult to maintain, it is difficult to test, it is difficult to extend. etc etc. Instead, I was advocating for an approach where GP and Neutron Core integrate via (a well defined and stable) REST API, or similar (more abstracted) mechanisms; this has obvious benefits because the two become suddenly loosely coupled: a change done in the way Neutron deals with DHCP messages is not going to have any effect to how the GP plugin create resources. Also, any potential refactoring of the Neutron Core will not cause the GP team to take the burden of bringing the current implementation forward. This is why I was proposing that we talk about the introduction of integration hooks, should they (or lack thereof) have been the culprit of such an initial design approach. Please, take my comments as initial reviews to the above patches, if you will :) To be constructive, as a core reviewer who should suggest alternatives, I would invite the people reading this thread to have a look at [1] and [2]: these were introduced by RAX to their cut of Neutron, having in mind exactly what I have been saying: adding functionality with zero impact to existing code. If something along those lines can be achieved, then this would be very beneficial for the progress of the GP effort as it transitions and evolves into/within Neutron, IMO. Having said that, I am making these points without particular reference to the complexity of the GP model being proposed, or the approach being taken to introduce it to the tree. Even though I share some of Maru's points, good architecture and design principles in software development should be followed wherever possible and irrespective of the domain where such development occur. Many thanks, Armando [1] - https://github.com/roaet/wafflehaus [2] - https://github.com/roaet/wafflehaus.neutron Let me address them in that order. 1. Re: It is large Group policy has an ambitious goal - provide devop teams with policy based controls that are usable at scale and with automation (say a higher governance layer like Congress). The fact that meeting a large challenge requires more code is natural. We understand that challenge, and that is why we did a prototype (as PoC that was demonstrated on the summit). And based on that learning we are incrementally creating patches for building the group based policy. Just because a task is large, we as neutron can not shy away from building it. That will only drive people who need it out side neutron (as we are seeing with the frustration that the LBaaS team had because they have a requirement that is large as well). 2. Re: It is complex Complexity depends on the context. Our goal was to make the end-user's life simpler (and more automated). To achieve some of that simplicity, we required a little more complexity in the implementation. We decide to make that arbitrage - a little higher complexity in implementation to allow for simpler usage. But we were careful and did not want to impose that complexity on every use case - hence a lot of that is optional (and exercised only if the use case needs it). Unfortunately the model, has to model all of it so as it not add complexity later in upgrade and backward compatibility issues. We choose to do architecture upfront, and then implement it incrementally. The team came up with the model currently in model based on that review and evaluation all the proposals in the document that you refer. It is easy to make general comments, but unless you participate in the process and sign
Re: [openstack-dev] [neutron][group-based-policy] Should we revisit the priority of group-based policy?
Thanks to everyone who participated in the Group Policy meeting [1] earlier today. A lot of good discussion that hopefully will continue with participation from the larger community. I wanted to first make a comment about how the Group Policy work was received outside the Neutron community and then focus on finding a way for us to make progress. I think we had a really good feedback from the larger OpenStack community and I would say a wide support for addition of policy abstractions to Neutron. If the feedback we received at the summit in Hong Kong was mostly positive, in Atlanta the support was overwhelmingly positive in my opinion. I just wanted to make sure this does not get lost in our discussions. Needless to say, we will work on a path to have the Group Policy work included in Neutron in a way that keeps the quality of code in Neutron preserved. To rephrase what Armando said in the IRC meeting earlier today, we all share a common goal and that is to do what's right. I think it may be beneficial that for the moment and for the next few days as we try to find the best path forward, we forget about any particular cycle/milestone/priority and look for the best path forward and see where that leads us. To this end, the group policy team will be setting up a meeting with Armando (and others who are interested) to in particular discuss the possibility of making the code less tightly coupled with Neutron core. We will also consider how we can address Marun's and Mark's concerns by trying to have a simpler but functional set of patches that can be reviewed more effectively such that we can build on them in an iterative manner. Meanwhile, please do continue the discussion on the mailing list. Best, Mohammad [1] https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy From: Armando M. arma...@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org, Date: 05/22/2014 11:24 PM Subject:Re: [openstack-dev] [neutron][group-based-policy] Should we revisit the priority of group-based policy? On 22 May 2014 13:59, Mandeep Dhami dh...@noironetworks.com wrote: Maru's concerns are that: 1. It is large 2. It is complex And Armando's related concerns are: 3. Could dev/review cycles be better spent on refactoring 4. If refactored neutron was available, would a simpler option become more viable This is not what I meant to say, and if this was the message that came across I apologize for the confusion; let me rephrase: After looking (and relooking) at the initial patches proposed I started to question why the GP plugin functionality was so tightly integrated with the Neutron core functionality; even though I might guess the thinking process, I wonder if such tight coupling was the result of design decisions made without thoroughly considering alternative approaches. Without going too much into details during this email, I can see in the above mentioned patches that lots of plumbing code (like Nova and dhcp notifiers handling code) is put in place to make direct calls to core plugin methods: this spills implementation details across multiple parts of the project; it's fragile because it's prone to ripple effects due to lack of proper encapsulation: if a change is made in the plugin API or its implementation, the whole thing needs to be looked at, end-to-end: this does not scale from a human perspective (probably only a handful of people can really say that they know the Neutron codebase inside-out), it is difficult to maintain, it is difficult to test, it is difficult to extend. etc etc. Instead, I was advocating for an approach where GP and Neutron Core integrate via (a well defined and stable) REST API, or similar (more abstracted) mechanisms; this has obvious benefits because the two become suddenly loosely coupled: a change done in the way Neutron deals with DHCP messages is not going to have any effect to how the GP plugin create resources. Also, any potential refactoring of the Neutron Core will not cause the GP team to take the burden of bringing the current implementation forward. This is why I was proposing that we talk about the introduction of integration hooks, should they (or lack thereof) have been the culprit of such an initial design approach. Please, take my comments as initial reviews to the above patches, if you will :) To be constructive, as a core reviewer who should suggest alternatives, I would invite the people reading this thread to have a look at [1] and [2]: these were introduced by RAX to their cut of Neutron, having in mind exactly what I have been saying: adding functionality with zero impact to existing code. If something along those lines can be achieved, then this would be very beneficial for the progress of the GP effort as it transitions and evolves into/within Neutron, IMO. Having said that, I am making these points without particular reference to the complexity
Re: [openstack-dev] [neutron][group-based-policy] Should we revisit the priority of group-based policy?
Hi Armando: Those are good points. I will let Bob Kukura chime in on the specifics of how we intend to do that integration. But if what you see in the prototype/PoC was our final design for integration with Neutron core, I would be worried about that too. That specific part of the code (events/notifications for DHCP) was done in that way just for the prototype - to allow us to experiment with the part that was new and needed experimentation, the APIs and the model. That is the exact reason that we did not initially check the code to gerrit - so that we do not confuse the review process with the prototype process. But we were requested by other cores to check in even the prototype code as WIP patches to allow for review of the API parts. That can unfortunately create this very misunderstanding. For the review, I would recommend not the WIP patches, as they contain the prototype parts as well, but just the final patches that are not marked WIP. If you such issues in that part of the code, please DO raise that as that would be code that we intend to upstream. I believe Bob did discuss the specifics of this integration issue with you at the summit, but like I said it is best if he represents that side himself. Regards, Mandeep On Thu, May 22, 2014 at 8:19 PM, Armando M. arma...@gmail.com wrote: On 22 May 2014 13:59, Mandeep Dhami dh...@noironetworks.com wrote: Maru's concerns are that: 1. It is large 2. It is complex And Armando's related concerns are: 3. Could dev/review cycles be better spent on refactoring 4. If refactored neutron was available, would a simpler option become more viable This is not what I meant to say, and if this was the message that came across I apologize for the confusion; let me rephrase: After looking (and relooking) at the initial patches proposed I started to question why the GP plugin functionality was so tightly integrated with the Neutron core functionality; even though I might guess the thinking process, I wonder if such tight coupling was the result of design decisions made without thoroughly considering alternative approaches. Without going too much into details during this email, I can see in the above mentioned patches that lots of plumbing code (like Nova and dhcp notifiers handling code) is put in place to make direct calls to core plugin methods: this spills implementation details across multiple parts of the project; it's fragile because it's prone to ripple effects due to lack of proper encapsulation: if a change is made in the plugin API or its implementation, the whole thing needs to be looked at, end-to-end: this does not scale from a human perspective (probably only a handful of people can really say that they know the Neutron codebase inside-out), it is difficult to maintain, it is difficult to test, it is difficult to extend. etc etc. Instead, I was advocating for an approach where GP and Neutron Core integrate via (a well defined and stable) REST API, or similar (more abstracted) mechanisms; this has obvious benefits because the two become suddenly loosely coupled: a change done in the way Neutron deals with DHCP messages is not going to have any effect to how the GP plugin create resources. Also, any potential refactoring of the Neutron Core will not cause the GP team to take the burden of bringing the current implementation forward. This is why I was proposing that we talk about the introduction of integration hooks, should they (or lack thereof) have been the culprit of such an initial design approach. Please, take my comments as initial reviews to the above patches, if you will :) To be constructive, as a core reviewer who should suggest alternatives, I would invite the people reading this thread to have a look at [1] and [2]: these were introduced by RAX to their cut of Neutron, having in mind exactly what I have been saying: adding functionality with zero impact to existing code. If something along those lines can be achieved, then this would be very beneficial for the progress of the GP effort as it transitions and evolves into/within Neutron, IMO. Having said that, I am making these points without particular reference to the complexity of the GP model being proposed, or the approach being taken to introduce it to the tree. Even though I share some of Maru's points, good architecture and design principles in software development should be followed wherever possible and irrespective of the domain where such development occur. Many thanks, Armando [1] - https://github.com/roaet/wafflehaus [2] - https://github.com/roaet/wafflehaus.neutron Let me address them in that order. 1. Re: It is large Group policy has an ambitious goal - provide devop teams with policy based controls that are usable at scale and with automation (say a higher governance layer like Congress). The fact that meeting a large challenge requires more code is natural. We understand that
