[openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

Jay Pipes jaypipes at gmail.com
Fri Aug 8 16:28:27 UTC 2014

On 08/08/2014 08:55 AM, Kevin Benton wrote:
> The existing constructs will not change.

A followup question on the above...

If GPB API is merged into Neutron, the next logical steps (from what I 
can tell) will be to add drivers that handle policy-based payloads/requests.

Some of these drivers, AFAICT, will *not* be deconstructing these policy 
requests into the low-level port, network, and subnet 
creation/attachment/detachment commands, but instead will be calling out 
as-is to hardware that speaks the higher-level abstraction API [1], not 
the lower-level port/subnet/network APIs. The low-level APIs would 
essentially be consumed entirely within the policy-based driver, which 
would effectively mean that the only way a system would be able to 
orchestrate networking in systems using these drivers would be via the 
high-level policy API.

Is that correct? Very sorry if I haven't explained clearly my 
question... this is a tough question to frame eloquently :(



> On Aug 8, 2014 9:49 AM, "CARVER, PAUL" <pc2929 at att.com
> <mailto:pc2929 at att.com>> wrote:
>     Wuhongning [mailto:wuhongning at huawei.com
>     <mailto:wuhongning at huawei.com>] wrote:
>      >Does it make sense to move all advanced extension out of ML2, like
>     security
>      >group, qos...? Then we can just talk about advanced service
>     itself, without
>      >bothering basic neutron object (network/subnet/port)
>     A modular layer 3 (ML3) analogous to ML2 sounds like a good idea. I
>     still
>     think it's too late in the game to be shooting down all the work
>     that the
>     GBP team has put in unless there's a really clean and effective way of
>     running AND iterating on GBP in conjunction with Neutron without being
>     part of the Juno release. As far as I can tell they've worked really
>     hard to follow the process and accommodate input. They shouldn't have
>     to wait multiple more releases on a hypothetical refactoring of how
>     L3+ vs
>     L2 is structured.
>     But, just so I'm not making a horrible mistake, can someone reassure me
>     that GBP isn't removing the constructs of network/subnet/port from
>     Neutron?
>     I'm under the impression that GBP is adding a higher level abstraction
>     but that it's not ripping basic constructs like network/subnet/port out
>     of the existing API. If I'm wrong about that I'll have to change my
>     opinion. We need those fundamental networking constructs to be present
>     and accessible to users that want/need to deal with them. I'm viewing
>     GBP as just a higher level abstraction over the top.
>     _______________________________________________
>     OpenStack-dev mailing list
>     OpenStack-dev at lists.openstack.org
>     <mailto: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

More information about the OpenStack-dev mailing list