<p dir="ltr">As long as the discussion stays focused on how group policies are beneficial for the user community and how the Neutron developer community should move forward, I reckon it's fine to keep the discussion in this thread.</p>
<p dir="ltr">Salvatore</p>
<div class="gmail_quote">Il 06/ago/2014 21:18 "Aaron Rosen" <<a href="mailto:aaronorosen@gmail.com">aaronorosen@gmail.com</a>> ha scritto:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Hi Kevin, <div><br></div><div>I think we should keep these threads together as we need to understand the benefit collectively before we move forward with what to do. </div><div><br></div><div>Aaron</div></div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Aug 6, 2014 at 12:03 PM, Kevin Benton <span dir="ltr"><<a href="mailto:blak111@gmail.com" target="_blank">blak111@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p dir="ltr">Hi Aaron, </p>
<p dir="ltr">These are good questions, but can we move this to a different thread labeled "what is the point of group policy?" </p>
<p dir="ltr">I don't want to derail this one again and we should stick to Salvatore's options about the way to move forward with these code changes. </p><div><div>
<div class="gmail_quote">On Aug 6, 2014 12:42 PM, "Aaron Rosen" <<a href="mailto:aaronorosen@gmail.com" target="_blank">aaronorosen@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><p style="font-family:arial,sans-serif;font-size:12.666666984558105px;margin-bottom:0in"><span style="line-height:13px">Hi,</span></p><p style="font-family:arial,sans-serif;font-size:12.666666984558105px;margin-bottom:0in">
<span style="line-height:13px">I've made my way through the group based policy code and blueprints and I'd like ask several questions about it. My first question really is what is the advantage that the new proposed group based policy model buys us? </span><br>
</p><p style="font-family:arial,sans-serif;font-size:12.666666984558105px;margin-bottom:0in"><span style="line-height:13px"><br></span></p><blockquote class="gmail_quote" style="font-family:arial,sans-serif;font-size:12.666666984558105px;margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span style="line-height:13px">Bobs says, "The group-based policy BP approved for Juno addresses the critical need for a more usable, declarative, intent-based interface for cloud application developers and deployers, that can co-exist with Neutron's current networking-hardware-oriented API and work nicely with all existing core plugins. Additionally, we believe that this declarative approach is what is needed to properly integrate advanced services into Neutron, and will go a long way towards resolving the difficulties so far trying to integrate LBaaS, FWaaS, and VPNaaS APIs into the current Neutron model."</span></blockquote>
<p style="font-family:arial,sans-serif;font-size:12.666666984558105px;margin-bottom:0in"><span style="line-height:13px">My problem with the current blueprint and that comment above is it does not provide any evidence or data of where the current neutron abstractions (ports/networks/subnets/routers) provide difficulties and what benefit this new model will provide. </span><br>
</p><p style="font-family:arial,sans-serif;font-size:12.666666984558105px;margin-bottom:0in"><span style="line-height:13px">In the current proposed implementation of group policy, it's implementation maps onto the existing neutron primitives and the neutron back end(s) remains unchanged. Because of this one can map the new abstractions onto the previous ones so I'm curious why we want to move this complexity into neutron and not have it done externally similarly to how heat works or a client that abstracts this complexity on it's own end. </span><br>
</p><div style="font-family:arial,sans-serif;font-size:12.666666984558105px"><div><br></div><p style="margin-bottom:0in;line-height:13px">From the group-based policy blueprint that was submitted [1]:<br></p><p style="margin-bottom:0in;line-height:13px">
<br></p><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">The current Neutron model of networks, ports, subnets, routers, and security<br>
groups provides the necessary building blocks to build a logical network<br>topology for connectivity. However, it does not provide the right level<br>of abstraction for an application administrator who understands the<br>
application's details (like application port numbers), but not the<br>infrastructure details likes networks and routes.</blockquote></div><p style="font-family:arial,sans-serif;font-size:12.666666984558105px;margin-bottom:0in">
<span style="line-height:13px">It looks to me that application </span><span style="line-height:13px">administrators</span><span style="line-height:13px"> still need to understand network primitives as the concept of networks/ports/routers are still present though just carrying a different name. For example, in ENDPOINT_GROUPS there is an attribute l2_policy_id which maps to something that you use to describe a l2_network and contains an attribute l3_policy_id which is used to describe an L3 network. This looks similar to the abstraction we have today where a l2_policy (network) then can have multiple l3_policies (subnets) mapping to it. Because of this I'm curious how the GBP abstraction really provides a different level of abstraction for application administrators. </span><br>
</p><div style="font-family:arial,sans-serif;font-size:12.666666984558105px"><p style="margin-bottom:0in"><span style="line-height:13px"><br></span></p><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
Not only that, the current<br>abstraction puts the burden of maintaining the consistency of the network<br>topology on the user. The lack of application developer/administrator focussed<br>abstractions supported by a declarative model make it hard for those users<br>
to consume Neutron as a connectivity layer.</blockquote></div><p style="font-family:arial,sans-serif;font-size:12.666666984558105px;margin-bottom:0in"><span style="line-height:13px">What is the problem in the current abstraction that puts a burden of maintaining the consistency of networking topology on users? It seems to me that the complexity of having to know about topology should be abstracted at the client layer if desired (and neutron should expose the basic building blocks for networking). For example, Horizon/Heat or the CLI could hide the requirement of topology by automatically creating a GROUP (which is a network+subnet on a router uplinked to an external network) simplifying this need for the tenant to understand topology. In addition, topology still seems to be present in the group policy model proposed just in a different way as I see it. </span></p>
<div style="font-family:arial,sans-serif;font-size:12.666666984558105px"><div><div><div></div></div></div><div><p style="margin-bottom:0in"><span style="line-height:13px">From the proposed change section the following is stated: </span><br>
</p><p style="margin-bottom:0in;line-height:13px"><br></p><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
This proposal suggests a model that allows application administrators to<br>express their networking requirements using group and policy abstractions, with<br>the specifics of policy enforcement and implementation left to the underlying<br>
policy driver. The main advantage of the extensions described in this blueprint<br>is that they allow for an application-centric interface to Neutron that<br>complements the existing network-centric interface.</blockquote>
<div><br></div><div>How is the Application-centric interface complementary to the network-centric interface? Is the intention that one would use both interfaces at one once? </div><div><br></div></div></div><div style="font-family:arial,sans-serif;font-size:12.666666984558105px">
<div><div><div><div></div></div></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
More specifically the new abstractions will achieve the following:<br>* Show clear separation of concerns between application and infrastructure<br>administrator.<br></blockquote><div><br></div><div>I'm not quite sure I understand this point, how is this different than what we have today? </div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">- The application administrator can then deal with a higher level abstraction<br>
that does not concern itself with networking specifics like<br>networks/routers/etc.<br></blockquote><div><br></div><div>It seems like the proposed abstraction still requires one to concern themselves with networking specifics (l2_policies, l3_policies). I'd really like to see more evidence backing this. Now they have to deal with specifies like: Endpoint, Endpoint Group, Contract, Policy Rule, Classifier, Action, Filter, Role, Contract Scope, Selector, Policy Label, Bridge Domain, Routing Domain...</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">- The infrastructure administrator will deal with infrastructure specific<br>
policy abstractions and not have to understand application specific concerns<br>like specific ports that have been opened or which of them expect to be<br>limited to secure or insecure traffic. The infrastructure admin will also</blockquote>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">have ability to direct which technologies and approaches used in rendering.<br>
For example, if VLAN or VxLAN is used.<br></blockquote><div><br></div><div>How is this different from what we have now? Today in neutron the infrastructure administrator deals with infrastructure specific policy abstractions i.e external networks (networks that uplink to the physical world) and do not have to understand any specific connectivity concerns of the application as mentioned is provided in this model. Since the beginning neutron has always given the ability for infra admins to decide which back-end technologies are used VXLAN/VLAN/etc which are abstracted away from the tenant. </div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">- Allow the infrastructure admin to introduce connectivity constraints<br>
without the application administrator having to be aware of it (e.g. audit<br>all traffic between two application tiers).<br></blockquote><div><br></div><div>I think this is a good point and see how this works in the Group Based Policy abstractions that are proposed. That said, I think there are other ways to provide this type of interface rather redefining the current abstractions. For example, providing additional attributes on the existing primitives (ports/networks/router) to get this information. Or similarly how the LBaaS/Security Group API was implemented providing a grouping concept.</div>
<div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">* Allow for independent provider/consumer model with late binding and n-to-m<br>
relationships between them.<br></blockquote><div><br></div><div>Same points as above. I still don't understand how changing this model provides us anything different (or advantage) that we already have/(or can) today. Also, reading through the current model it seems like it ties the bindings to endpoint-groups (networks) rather than endpoints (ports) which seems like a restriction we'd like to avoid. What I mean by this is it looks like security groups are now mapped to networks rather than ports requiring one to break an application up on to different networks (which we do not require today). </div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">* Allow for automatic orchestration that can respond to changes in policy or<br>
infrastructure without requiring human interaction to translate intent to<br>specific actions.</blockquote><div><br></div><div>I'd be curious to hear more about this and how changing the abstractions today makes this easier. How does the automatic orchestration work? There is actually a heat blueprint that talks about getting infrastructure to desired state without human interaction (which is able to do this without changing any of the abstractions in neutron/nova) - <a href="https://review.openstack.org/#/c/95907/" target="_blank">https://review.openstack.org/#/c/95907/</a> </div>
<div> </div></div></div><div> Another concern is that the new API provides several new constructs I think users will have difficultly understanding: </div><div><div><div><div>
</div></div></div><div><div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">The following new terminology is being introduced:<br>
**Endpoint (EP):** An L2/L3 addressable entity.<br>**Endpoint Group (EPG):** A collection of endpoints.<br>**Contract:** It defines how the application services provided by an EPG can be<br>accessed. In effect it specifies how an EPG communicates with other EPGs. A<br>
Contract consists of Policy Rules.<br>**Policy Rule:** These are individual rules used to define the communication<br>criteria between EPGs. Each rule contains a Filter, Classifier, and Action.<br>**Classifier:** Characterizes the traffic that a particular Policy Rule acts on.<br>
Corresponding action is taken on traffic that satisfies this classification<br>criteria.<br>**Action:** The action that is taken for a matching Policy Rule defined in a<br>Contract.<br>**Filter:** Provides a way to tag a Policy Rule with Capability and Role labels.<br>
**Capability:** It is a Policy Label that defines what part of a Contract a<br>particular EPG provides.<br>**Role:** It is a Policy Label that defines what part of a Contract an EPG wants<br>to consume.<br>**Contract Scope:** An EPG conveys its intent to provide or consume a Contract<br>
(or its part) by defining a Contract Scope which references the target<br>Contract.<br>**Selector:** A Contract Scope can define additional constraints around choosing<br>the matching provider or consumer EPGs for a Contract via a Selector.<br>
**Policy Labels:** These are labels contained within a namespace hierarchy and<br>used to define Capability and Role tags used in Filters.<br>**Bridge Domain:** Used to define a L2 boundary and impose additional<br>constraints (such as no broadcast) within that L2 boundary.<br>
**Routing Domain:** Used to define a non-overlapping IP address space.</blockquote></div><div><br></div><div><br></div></div></div></div><div style="font-family:arial,sans-serif;font-size:12.666666984558105px"><div>
<div><div></div></div></div><div><div>I was also not able to find out how policy labels, selector, capabilities, filters, and roles are used and how they work (I haven't found patches yet that use these either). </div>
<div><br></div></div></div><div style="font-family:arial,sans-serif;font-size:12.666666984558105px">Lastly, I believe the neutron API was built with the desire of simplicity and providing an abstraction that represents how networks works (similar to nova for servers). It provides the basic building block to allow one to implement any networking concept or orchestration they desire on top of it. I think this speaks to the point that the API we have today is flexible enough for the concept of group policy to be mapped directly on top of it. I do see the benefit for a higher level abstraction though I don't really understand the benefit that this new model buys us. I look forward to continuing this discussion. </div>
<div style="font-family:arial,sans-serif;font-size:12.666666984558105px"><br></div><div style="font-family:arial,sans-serif;font-size:12.666666984558105px">Best, </div><div class="gmail_extra"><br></div><div class="gmail_extra">
Aaron</div><div class="gmail_extra"><br></div><div class="gmail_extra">[1] - <a href="https://github.com/openstack/neutron-specs/blob/master/specs/juno/group-based-policy-abstraction.rst" target="_blank">https://github.com/openstack/neutron-specs/blob/master/specs/juno/group-based-policy-abstraction.rst</a><br>
<br><div class="gmail_quote">On Wed, Aug 6, 2014 at 11:04 AM, Jay Pipes <span dir="ltr"><<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div><div>On 08/06/2014 04:30 AM, Stefano Santini wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Hi,<br>
<br>
In my company (Vodafone), we (DC network architecture) are following<br>
very closely the work happening on Group Based Policy since we see a<br>
great value on the new paradigm to drive network configurations with an<br>
advanced logic.<br>
<br>
We're working on a new production project for an internal private cloud<br>
deployment targeting Juno release where we plan to introduce the<br>
capabilities based on using Group Policy and we don't want to see it<br>
delayed.<br>
We strongly request/vote to see this complete as proposed without such<br>
changes to allow to move forward with the evolution of the network<br>
capabilities<br>
</blockquote>
<br></div></div>
Hi Stefano,<br>
<br>
AFAICT, there is nothing that can be done with the GBP API that cannot be done with the low-level regular Neutron API.<br>
<br>
Further, if the Nova integration of the GBP API does not occur in the Juno timeframe, what benefit will GBP in Neutron give you? Specifics on the individual API calls that you would change would be most appreciated.<br>
<br>
Thanks in advance for your input!<span><font color="#888888"><br>
-jay</font></span><div><div><br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div>
</div></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div>