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.


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

Reply via email to