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.
Salvatore Il 06/ago/2014 21:18 "Aaron Rosen" <aaronoro...@gmail.com> ha scritto: > Hi Kevin, > > I think we should keep these threads together as we need to understand the > benefit collectively before we move forward with what to do. > > Aaron > > > On Wed, Aug 6, 2014 at 12:03 PM, Kevin Benton <blak...@gmail.com> wrote: > >> Hi Aaron, >> >> These are good questions, but can we move this to a different thread >> labeled "what is the point of group policy?" >> >> 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. >> On Aug 6, 2014 12:42 PM, "Aaron Rosen" <aaronoro...@gmail.com> wrote: >> >>> Hi, >>> >>> 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? >>> >>> >>> 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." >>> >>> 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. >>> >>> 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. >>> >>> From the group-based policy blueprint that was submitted [1]: >>> >>> >>> The current Neutron model of networks, ports, subnets, routers, and >>>> security >>>> groups provides the necessary building blocks to build a logical network >>>> topology for connectivity. However, it does not provide the right level >>>> of abstraction for an application administrator who understands the >>>> application's details (like application port numbers), but not the >>>> infrastructure details likes networks and routes. >>> >>> It looks to me that application administrators 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. >>> >>> >>> Not only that, the current >>>> abstraction puts the burden of maintaining the consistency of the >>>> network >>>> topology on the user. The lack of application developer/administrator >>>> focussed >>>> abstractions supported by a declarative model make it hard for those >>>> users >>>> to consume Neutron as a connectivity layer. >>> >>> 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. >>> >>> From the proposed change section the following is stated: >>> >>> >>> This proposal suggests a model that allows application administrators to >>>> express their networking requirements using group and policy >>>> abstractions, with >>>> the specifics of policy enforcement and implementation left to the >>>> underlying >>>> policy driver. The main advantage of the extensions described in this >>>> blueprint >>>> is that they allow for an application-centric interface to Neutron that >>>> complements the existing network-centric interface. >>> >>> >>> How is the Application-centric interface complementary to the >>> network-centric interface? Is the intention that one would use both >>> interfaces at one once? >>> >>> More specifically the new abstractions will achieve the following: >>>> * Show clear separation of concerns between application and >>>> infrastructure >>>> administrator. >>>> >>> >>> I'm not quite sure I understand this point, how is this different than >>> what we have today? >>> >>> >>>> - The application administrator can then deal with a higher level >>>> abstraction >>>> that does not concern itself with networking specifics like >>>> networks/routers/etc. >>>> >>> >>> 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... >>> >>> >>>> - The infrastructure administrator will deal with infrastructure >>>> specific >>>> policy abstractions and not have to understand application specific >>>> concerns >>>> like specific ports that have been opened or which of them expect to be >>>> limited to secure or insecure traffic. The infrastructure admin will >>>> also >>> >>> have ability to direct which technologies and approaches used in >>>> rendering. >>>> For example, if VLAN or VxLAN is used. >>>> >>> >>> 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. >>> >>> - Allow the infrastructure admin to introduce connectivity constraints >>>> without the application administrator having to be aware of it (e.g. >>>> audit >>>> all traffic between two application tiers). >>>> >>> >>> 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. >>> >>> >>> >>>> * Allow for independent provider/consumer model with late binding and >>>> n-to-m >>>> relationships between them. >>>> >>> >>> 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). >>> >>> >>>> * Allow for automatic orchestration that can respond to changes in >>>> policy or >>>> infrastructure without requiring human interaction to translate intent >>>> to >>>> specific actions. >>> >>> >>> 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) - >>> https://review.openstack.org/#/c/95907/ >>> >>> Another concern is that the new API provides several new constructs I >>> think users will have difficultly understanding: >>> >>> The following new terminology is being introduced: >>>> **Endpoint (EP):** An L2/L3 addressable entity. >>>> **Endpoint Group (EPG):** A collection of endpoints. >>>> **Contract:** It defines how the application services provided by an >>>> EPG can be >>>> accessed. In effect it specifies how an EPG communicates with other >>>> EPGs. A >>>> Contract consists of Policy Rules. >>>> **Policy Rule:** These are individual rules used to define the >>>> communication >>>> criteria between EPGs. Each rule contains a Filter, Classifier, and >>>> Action. >>>> **Classifier:** Characterizes the traffic that a particular Policy Rule >>>> acts on. >>>> Corresponding action is taken on traffic that satisfies this >>>> classification >>>> criteria. >>>> **Action:** The action that is taken for a matching Policy Rule defined >>>> in a >>>> Contract. >>>> **Filter:** Provides a way to tag a Policy Rule with Capability and >>>> Role labels. >>>> **Capability:** It is a Policy Label that defines what part of a >>>> Contract a >>>> particular EPG provides. >>>> **Role:** It is a Policy Label that defines what part of a Contract an >>>> EPG wants >>>> to consume. >>>> **Contract Scope:** An EPG conveys its intent to provide or consume a >>>> Contract >>>> (or its part) by defining a Contract Scope which references the target >>>> Contract. >>>> **Selector:** A Contract Scope can define additional constraints around >>>> choosing >>>> the matching provider or consumer EPGs for a Contract via a Selector. >>>> **Policy Labels:** These are labels contained within a namespace >>>> hierarchy and >>>> used to define Capability and Role tags used in Filters. >>>> **Bridge Domain:** Used to define a L2 boundary and impose additional >>>> constraints (such as no broadcast) within that L2 boundary. >>>> **Routing Domain:** Used to define a non-overlapping IP address space. >>> >>> >>> >>> 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). >>> >>> 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. >>> >>> Best, >>> >>> Aaron >>> >>> [1] - >>> https://github.com/openstack/neutron-specs/blob/master/specs/juno/group-based-policy-abstraction.rst >>> >>> On Wed, Aug 6, 2014 at 11:04 AM, Jay Pipes <jaypi...@gmail.com> wrote: >>> >>>> On 08/06/2014 04:30 AM, Stefano Santini wrote: >>>> >>>>> Hi, >>>>> >>>>> In my company (Vodafone), we (DC network architecture) are following >>>>> very closely the work happening on Group Based Policy since we see a >>>>> great value on the new paradigm to drive network configurations with an >>>>> advanced logic. >>>>> >>>>> We're working on a new production project for an internal private cloud >>>>> deployment targeting Juno release where we plan to introduce the >>>>> capabilities based on using Group Policy and we don't want to see it >>>>> delayed. >>>>> We strongly request/vote to see this complete as proposed without such >>>>> changes to allow to move forward with the evolution of the network >>>>> capabilities >>>>> >>>> >>>> Hi Stefano, >>>> >>>> AFAICT, there is nothing that can be done with the GBP API that cannot >>>> be done with the low-level regular Neutron API. >>>> >>>> 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. >>>> >>>> Thanks in advance for your input! >>>> -jay >>>> >>>> >>>> _______________________________________________ >>>> OpenStack-dev mailing list >>>> OpenStack-dev@lists.openstack.org >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>> >>> >>> _______________________________________________ >>> OpenStack-dev mailing list >>> OpenStack-dev@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > _______________________________________________ > OpenStack-dev 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
