Open Stack

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 <blak111 at 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" <aaronorosen at 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 <jaypipes at 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 at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140806/02931a2f/attachment-0001.html>