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 :(
Thanks,
-jay
[1]
http://www.cisco.com/c/en/us/solutions/data-center-virtualization/application-centric-infrastructure/index.html
On Aug 8, 2014 9:49 AM, "CARVER, PAUL" <pc2...@att.com
<mailto:pc2...@att.com>> wrote:
Wuhongning [mailto:wuhongn...@huawei.com
<mailto:wuhongn...@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@lists.openstack.org
<mailto: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