settingsLogin | Registersettings

[openstack-dev] [neutron] ML2 versus core plugin for OVN

0 votes

[branching off a discussion on ovs-dev at this point:
http://openvswitch.org/pipermail/dev/2015-February/051609.html]

On Fri, Feb 20, 2015 at 6:56 PM, Kyle Mestery mestery@mestery.com wrote:

One thing to keep in mind, this ties somewhat into my response to Russell
earlier on the decision around ML2 vs. core plugin. If we do ML2, there are
type drivers for VLAN, VXLAN, and GRE tunnels. There is no TypeDriver for
STT tunnels upstream now. It's just an item we need on the TODO list if we
go down the STT tunnel path.

It was suggested to me off-list that this part of the discussion should be on
openstack-dev, so here it is ;-)


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked Feb 23, 2015 in openstack-dev by Ben_Pfaff (620 points)   1 2
retagged Apr 14, 2015 by admin

24 Responses

0 votes

I think there are a few factors which influence the ML2 driver vs
"monolithic" plugin debate, and they mostly depend on OVN rather than
Neutron.
From a Neutron perspective both plugins and drivers (as long at they live
in their own tree) will be supported in the foreseeable future. If a ML2
mech driver is not the best option for OVN that would be ok - I don't think
the Neutron community advices development of a ML2 driver as the preferred
way for integrating with new backends.

The ML2 framework provides a long list of benefits that mechanism driver
developer can leverage.
Among those:
- The ability of leveraging Type drivers which relieves driver developers
from dealing with network segment allocation
- Post-commit and (for most operations) pre-commit hooks for performing
operation on the backend
- The ability to leverage some of the features offered by Neutron's
built-in control-plane such as L2-population
- A flexible mechanism for enabling driver-specific API extensions
- Promotes modular development and integration with higher-layer services,
such as L3. For instance OVN could provide the L2 support for Neutron's
built-in L3 control plane
- The (potential afaict) ability of interacting with other mechanism driver
such as those operating on physical appliances on the data center
-

In my opinion OVN developers should look at ML2 benefits, and check which
ones apply to this specific platform. I'd say that if there are 1 or 2
checks in the above list, maybe it would be the case to look at developing
a ML2 mechanism driver, and perhaps a L3 service plugin.
It is worth nothing that ML2, thanks to its type and mechanism driver
provides also some control plane capabilities. If those capabilities are
however on OVN's roadmap it might be instead worth looking at a
"monolithic" plugin, which can also be easily implemented by inheriting
from neutron.db.dbbaseplugin_v2.NeutronDbPluginV2, and then adding all
the python mixins for the extensions the plugin needs to support.

Salvatore

On 23 February 2015 at 18:32, Ben Pfaff blp@nicira.com wrote:

[branching off a discussion on ovs-dev at this point:
http://openvswitch.org/pipermail/dev/2015-February/051609.html]

On Fri, Feb 20, 2015 at 6:56 PM, Kyle Mestery mestery@mestery.com wrote:

One thing to keep in mind, this ties somewhat into my response to Russell
earlier on the decision around ML2 vs. core plugin. If we do ML2, there
are
type drivers for VLAN, VXLAN, and GRE tunnels. There is no TypeDriver for
STT tunnels upstream now. It's just an item we need on the TODO list if
we
go down the STT tunnel path.

It was suggested to me off-list that this part of the discussion should be
on
openstack-dev, so here it is ;-)


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Feb 23, 2015 by Salvatore_Orlando (12,280 points)   2 5 8
0 votes

I want to emphasize Salvatore's last two points a bit more. If you go with
a monolithic plugin, you eliminate the possibility of heterogenous
deployments.

One example of this that is common now is having the current OVS driver
responsible for setting up the vswitch and then having a ToR driver (e.g.
Big Switch, Arista, etc) responsible for setting up the fabric.
Additionally, there is a separate L3 plugin (e.g. the reference one,
Vyatta, etc) for providing routing.

I suppose with an overlay it's easier to take the route that you don't want
to be compatible with other networking stuff at the Neutron layer (e.g.
integration with the 3rd parties is orchestrated somewhere else). In that
case, the above scenario wouldn't make much sense to support, but it's
worth keeping in mind.

On Mon, Feb 23, 2015 at 10:28 AM, Salvatore Orlando sorlando@nicira.com
wrote:

I think there are a few factors which influence the ML2 driver vs
"monolithic" plugin debate, and they mostly depend on OVN rather than
Neutron.
From a Neutron perspective both plugins and drivers (as long at they live
in their own tree) will be supported in the foreseeable future. If a ML2
mech driver is not the best option for OVN that would be ok - I don't think
the Neutron community advices development of a ML2 driver as the preferred
way for integrating with new backends.

The ML2 framework provides a long list of benefits that mechanism driver
developer can leverage.
Among those:
- The ability of leveraging Type drivers which relieves driver developers
from dealing with network segment allocation
- Post-commit and (for most operations) pre-commit hooks for performing
operation on the backend
- The ability to leverage some of the features offered by Neutron's
built-in control-plane such as L2-population
- A flexible mechanism for enabling driver-specific API extensions
- Promotes modular development and integration with higher-layer services,
such as L3. For instance OVN could provide the L2 support for Neutron's
built-in L3 control plane
- The (potential afaict) ability of interacting with other mechanism
driver such as those operating on physical appliances on the data center
-

In my opinion OVN developers should look at ML2 benefits, and check which
ones apply to this specific platform. I'd say that if there are 1 or 2
checks in the above list, maybe it would be the case to look at developing
a ML2 mechanism driver, and perhaps a L3 service plugin.
It is worth nothing that ML2, thanks to its type and mechanism driver
provides also some control plane capabilities. If those capabilities are
however on OVN's roadmap it might be instead worth looking at a
"monolithic" plugin, which can also be easily implemented by inheriting
from neutron.db.dbbaseplugin_v2.NeutronDbPluginV2, and then adding all
the python mixins for the extensions the plugin needs to support.

Salvatore

On 23 February 2015 at 18:32, Ben Pfaff blp@nicira.com wrote:

[branching off a discussion on ovs-dev at this point:
http://openvswitch.org/pipermail/dev/2015-February/051609.html]

On Fri, Feb 20, 2015 at 6:56 PM, Kyle Mestery mestery@mestery.com
wrote:

One thing to keep in mind, this ties somewhat into my response to
Russell
earlier on the decision around ML2 vs. core plugin. If we do ML2, there
are
type drivers for VLAN, VXLAN, and GRE tunnels. There is no TypeDriver
for
STT tunnels upstream now. It's just an item we need on the TODO list if
we
go down the STT tunnel path.

It was suggested to me off-list that this part of the discussion should
be on
openstack-dev, so here it is ;-)


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Kevin Benton


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Feb 23, 2015 by Kevin_Benton (24,800 points)   3 5 5
0 votes

Russel and I have already merged the initial ML2 skeleton driver [1]. The
thinking is that we can always revert to a non-ML2 driver if needed. I'm
not sure how useful having using OVN with other drivers will be, and that
was my initial concern with doing ML2 vs. full plugin. With the HW VTEP
support in OVN+OVS, you can tie in physical devices this way. Anyways, this
is where we're at for now. Comments welcome, of course.

Thanks,
Kyle

[1] https://github.com/stackforge/networking-ovn

On Mon, Feb 23, 2015 at 4:09 PM, Kevin Benton blak111@gmail.com wrote:

I want to emphasize Salvatore's last two points a bit more. If you go with
a monolithic plugin, you eliminate the possibility of heterogenous
deployments.

One example of this that is common now is having the current OVS driver
responsible for setting up the vswitch and then having a ToR driver (e.g.
Big Switch, Arista, etc) responsible for setting up the fabric.
Additionally, there is a separate L3 plugin (e.g. the reference one,
Vyatta, etc) for providing routing.

I suppose with an overlay it's easier to take the route that you don't
want to be compatible with other networking stuff at the Neutron layer
(e.g. integration with the 3rd parties is orchestrated somewhere else). In
that case, the above scenario wouldn't make much sense to support, but it's
worth keeping in mind.

On Mon, Feb 23, 2015 at 10:28 AM, Salvatore Orlando sorlando@nicira.com
wrote:

I think there are a few factors which influence the ML2 driver vs
"monolithic" plugin debate, and they mostly depend on OVN rather than
Neutron.
From a Neutron perspective both plugins and drivers (as long at they live
in their own tree) will be supported in the foreseeable future. If a ML2
mech driver is not the best option for OVN that would be ok - I don't think
the Neutron community advices development of a ML2 driver as the preferred
way for integrating with new backends.

The ML2 framework provides a long list of benefits that mechanism driver
developer can leverage.
Among those:
- The ability of leveraging Type drivers which relieves driver developers
from dealing with network segment allocation
- Post-commit and (for most operations) pre-commit hooks for performing
operation on the backend
- The ability to leverage some of the features offered by Neutron's
built-in control-plane such as L2-population
- A flexible mechanism for enabling driver-specific API extensions
- Promotes modular development and integration with higher-layer
services, such as L3. For instance OVN could provide the L2 support for
Neutron's built-in L3 control plane
- The (potential afaict) ability of interacting with other mechanism
driver such as those operating on physical appliances on the data center
-

In my opinion OVN developers should look at ML2 benefits, and check which
ones apply to this specific platform. I'd say that if there are 1 or 2
checks in the above list, maybe it would be the case to look at developing
a ML2 mechanism driver, and perhaps a L3 service plugin.
It is worth nothing that ML2, thanks to its type and mechanism driver
provides also some control plane capabilities. If those capabilities are
however on OVN's roadmap it might be instead worth looking at a
"monolithic" plugin, which can also be easily implemented by inheriting
from neutron.db.dbbaseplugin_v2.NeutronDbPluginV2, and then adding all
the python mixins for the extensions the plugin needs to support.

Salvatore

On 23 February 2015 at 18:32, Ben Pfaff blp@nicira.com wrote:

[branching off a discussion on ovs-dev at this point:
http://openvswitch.org/pipermail/dev/2015-February/051609.html]

On Fri, Feb 20, 2015 at 6:56 PM, Kyle Mestery mestery@mestery.com
wrote:

One thing to keep in mind, this ties somewhat into my response to
Russell
earlier on the decision around ML2 vs. core plugin. If we do ML2,
there are
type drivers for VLAN, VXLAN, and GRE tunnels. There is no TypeDriver
for
STT tunnels upstream now. It's just an item we need on the TODO list
if we
go down the STT tunnel path.

It was suggested to me off-list that this part of the discussion should
be on
openstack-dev, so here it is ;-)


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Kevin Benton


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Feb 24, 2015 by Kyle_Mestery (16,960 points)   3 3 6
0 votes

On 24 February 2015 at 01:34, Kyle Mestery mestery@mestery.com wrote:

Russel and I have already merged the initial ML2 skeleton driver [1].

The thinking is that we can always revert to a non-ML2 driver if needed.
>

If nothing else an authoritative decision on a design direction saves us
the hassle of going through iterations and discussions.
The integration through ML2 is definitely viable. My opinion however is
that since OVN implements a full control plane, the control plane bits
provided by ML2 are not necessary, and a plugin which provides only
management layer capabilities might be the best solution. Note: this does
not mean it has to be monolithic. We can still do L3 with a service plugin.
However, since the same kind of approach has been adopted for ODL I guess
this provides some sort of validation.

I'm not sure how useful having using OVN with other drivers will be, and
that was my initial concern with doing ML2 vs. full plugin. With the HW
VTEP support in OVN+OVS, you can tie in physical devices this way. Anyways,
this is where we're at for now. Comments welcome, of course.

That was also kind of my point regarding the control plane bits provided by
ML2 which OVN does not need. Still, the fact that we do not use a function
does not make any harm.
Also i'm not sure if OVN needs at all a type manager. If not, we can always
implement a no-op type manager, I guess.

Salvatore

Thanks,
Kyle

[1] https://github.com/stackforge/networking-ovn

On Mon, Feb 23, 2015 at 4:09 PM, Kevin Benton blak111@gmail.com wrote:

I want to emphasize Salvatore's last two points a bit more. If you go
with a monolithic plugin, you eliminate the possibility of heterogenous
deployments.

One example of this that is common now is having the current OVS driver
responsible for setting up the vswitch and then having a ToR driver (e.g.
Big Switch, Arista, etc) responsible for setting up the fabric.
Additionally, there is a separate L3 plugin (e.g. the reference one,
Vyatta, etc) for providing routing.

I suppose with an overlay it's easier to take the route that you don't
want to be compatible with other networking stuff at the Neutron layer
(e.g. integration with the 3rd parties is orchestrated somewhere else). In
that case, the above scenario wouldn't make much sense to support, but it's
worth keeping in mind.

On Mon, Feb 23, 2015 at 10:28 AM, Salvatore Orlando sorlando@nicira.com
wrote:

I think there are a few factors which influence the ML2 driver vs
"monolithic" plugin debate, and they mostly depend on OVN rather than
Neutron.
From a Neutron perspective both plugins and drivers (as long at they
live in their own tree) will be supported in the foreseeable future. If a
ML2 mech driver is not the best option for OVN that would be ok - I don't
think the Neutron community advices development of a ML2 driver as the
preferred way for integrating with new backends.

The ML2 framework provides a long list of benefits that mechanism driver
developer can leverage.
Among those:
- The ability of leveraging Type drivers which relieves driver
developers from dealing with network segment allocation
- Post-commit and (for most operations) pre-commit hooks for performing
operation on the backend
- The ability to leverage some of the features offered by Neutron's
built-in control-plane such as L2-population
- A flexible mechanism for enabling driver-specific API extensions
- Promotes modular development and integration with higher-layer
services, such as L3. For instance OVN could provide the L2 support for
Neutron's built-in L3 control plane
- The (potential afaict) ability of interacting with other mechanism
driver such as those operating on physical appliances on the data center
-

In my opinion OVN developers should look at ML2 benefits, and check
which ones apply to this specific platform. I'd say that if there are 1 or
2 checks in the above list, maybe it would be the case to look at
developing a ML2 mechanism driver, and perhaps a L3 service plugin.
It is worth nothing that ML2, thanks to its type and mechanism driver
provides also some control plane capabilities. If those capabilities are
however on OVN's roadmap it might be instead worth looking at a
"monolithic" plugin, which can also be easily implemented by inheriting
from neutron.db.dbbaseplugin_v2.NeutronDbPluginV2, and then adding all
the python mixins for the extensions the plugin needs to support.

Salvatore

On 23 February 2015 at 18:32, Ben Pfaff blp@nicira.com wrote:

[branching off a discussion on ovs-dev at this point:
http://openvswitch.org/pipermail/dev/2015-February/051609.html]

On Fri, Feb 20, 2015 at 6:56 PM, Kyle Mestery mestery@mestery.com
wrote:

One thing to keep in mind, this ties somewhat into my response to
Russell
earlier on the decision around ML2 vs. core plugin. If we do ML2,
there are
type drivers for VLAN, VXLAN, and GRE tunnels. There is no TypeDriver
for
STT tunnels upstream now. It's just an item we need on the TODO list
if we
go down the STT tunnel path.

It was suggested to me off-list that this part of the discussion should
be on
openstack-dev, so here it is ;-)


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Kevin Benton


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Feb 24, 2015 by Salvatore_Orlando (12,280 points)   2 5 8
0 votes

Even ignoring integration with other VXLAN based drivers inside of a
segment, using ML2 can allow someone to run a network with a mix of
segments using different segmentation types. As long as the OVN driver
understands which ports it is capable of binding, it can coexist with other
drivers and allow heterogenous setups 'for free'.

On Tue, Feb 24, 2015 at 1:19 AM, Salvatore Orlando sorlando@nicira.com
wrote:

On 24 February 2015 at 01:34, Kyle Mestery mestery@mestery.com wrote:

Russel and I have already merged the initial ML2 skeleton driver [1].

The thinking is that we can always revert to a non-ML2 driver if needed.
>

If nothing else an authoritative decision on a design direction saves us
the hassle of going through iterations and discussions.
The integration through ML2 is definitely viable. My opinion however is
that since OVN implements a full control plane, the control plane bits
provided by ML2 are not necessary, and a plugin which provides only
management layer capabilities might be the best solution. Note: this does
not mean it has to be monolithic. We can still do L3 with a service plugin.
However, since the same kind of approach has been adopted for ODL I guess
this provides some sort of validation.

I'm not sure how useful having using OVN with other drivers will be, and
that was my initial concern with doing ML2 vs. full plugin. With the HW
VTEP support in OVN+OVS, you can tie in physical devices this way. Anyways,
this is where we're at for now. Comments welcome, of course.

That was also kind of my point regarding the control plane bits provided
by ML2 which OVN does not need. Still, the fact that we do not use a
function does not make any harm.
Also i'm not sure if OVN needs at all a type manager. If not, we can
always implement a no-op type manager, I guess.

Salvatore

Thanks,
Kyle

[1] https://github.com/stackforge/networking-ovn

On Mon, Feb 23, 2015 at 4:09 PM, Kevin Benton blak111@gmail.com wrote:

I want to emphasize Salvatore's last two points a bit more. If you go
with a monolithic plugin, you eliminate the possibility of heterogenous
deployments.

One example of this that is common now is having the current OVS driver
responsible for setting up the vswitch and then having a ToR driver (e.g.
Big Switch, Arista, etc) responsible for setting up the fabric.
Additionally, there is a separate L3 plugin (e.g. the reference one,
Vyatta, etc) for providing routing.

I suppose with an overlay it's easier to take the route that you don't
want to be compatible with other networking stuff at the Neutron layer
(e.g. integration with the 3rd parties is orchestrated somewhere else). In
that case, the above scenario wouldn't make much sense to support, but it's
worth keeping in mind.

On Mon, Feb 23, 2015 at 10:28 AM, Salvatore Orlando <sorlando@nicira.com

wrote:

I think there are a few factors which influence the ML2 driver vs
"monolithic" plugin debate, and they mostly depend on OVN rather than
Neutron.
From a Neutron perspective both plugins and drivers (as long at they
live in their own tree) will be supported in the foreseeable future. If a
ML2 mech driver is not the best option for OVN that would be ok - I don't
think the Neutron community advices development of a ML2 driver as the
preferred way for integrating with new backends.

The ML2 framework provides a long list of benefits that mechanism
driver developer can leverage.
Among those:
- The ability of leveraging Type drivers which relieves driver
developers from dealing with network segment allocation
- Post-commit and (for most operations) pre-commit hooks for performing
operation on the backend
- The ability to leverage some of the features offered by Neutron's
built-in control-plane such as L2-population
- A flexible mechanism for enabling driver-specific API extensions
- Promotes modular development and integration with higher-layer
services, such as L3. For instance OVN could provide the L2 support for
Neutron's built-in L3 control plane
- The (potential afaict) ability of interacting with other mechanism
driver such as those operating on physical appliances on the data center
-

In my opinion OVN developers should look at ML2 benefits, and check
which ones apply to this specific platform. I'd say that if there are 1 or
2 checks in the above list, maybe it would be the case to look at
developing a ML2 mechanism driver, and perhaps a L3 service plugin.
It is worth nothing that ML2, thanks to its type and mechanism driver
provides also some control plane capabilities. If those capabilities are
however on OVN's roadmap it might be instead worth looking at a
"monolithic" plugin, which can also be easily implemented by inheriting
from neutron.db.dbbaseplugin_v2.NeutronDbPluginV2, and then adding all
the python mixins for the extensions the plugin needs to support.

Salvatore

On 23 February 2015 at 18:32, Ben Pfaff blp@nicira.com wrote:

[branching off a discussion on ovs-dev at this point:
http://openvswitch.org/pipermail/dev/2015-February/051609.html]

On Fri, Feb 20, 2015 at 6:56 PM, Kyle Mestery mestery@mestery.com
wrote:

One thing to keep in mind, this ties somewhat into my response to
Russell
earlier on the decision around ML2 vs. core plugin. If we do ML2,
there are
type drivers for VLAN, VXLAN, and GRE tunnels. There is no
TypeDriver for
STT tunnels upstream now. It's just an item we need on the TODO list
if we
go down the STT tunnel path.

It was suggested to me off-list that this part of the discussion
should be on
openstack-dev, so here it is ;-)


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Kevin Benton


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Kevin Benton


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Feb 24, 2015 by Kevin_Benton (24,800 points)   3 5 5
0 votes

On 24 February 2015 at 10:36, Kevin Benton blak111@gmail.com wrote:

Even ignoring integration with other VXLAN based drivers inside of a
segment, using ML2 can allow someone to run a network with a mix of
segments using different segmentation types. As long as the OVN driver
understands which ports it is capable of binding, it can coexist with other
drivers and allow heterogenous setups 'for free'.

It seems you're suggesting that ML2 is now able to integrate heterogenous
segments even when the drivers interfacing with their respective backends
ignore each other. In other words I can have a network with a segment
speaking VLANs and managed by driver "A", another segment speaking VxLAN
managed by driver "B", with ML2 providing you "for free" connectivity
between these two segment, thus achieving the heterogenous setup you were
mentioning.

I was unaware that such support was now available in ML2. In that case any
non-ML2 choice is probably a no brainer.

On Tue, Feb 24, 2015 at 1:19 AM, Salvatore Orlando sorlando@nicira.com
wrote:

On 24 February 2015 at 01:34, Kyle Mestery mestery@mestery.com wrote:

Russel and I have already merged the initial ML2 skeleton driver [1].

The thinking is that we can always revert to a non-ML2 driver if needed.
>

If nothing else an authoritative decision on a design direction saves us
the hassle of going through iterations and discussions.
The integration through ML2 is definitely viable. My opinion however is
that since OVN implements a full control plane, the control plane bits
provided by ML2 are not necessary, and a plugin which provides only
management layer capabilities might be the best solution. Note: this does
not mean it has to be monolithic. We can still do L3 with a service plugin.
However, since the same kind of approach has been adopted for ODL I guess
this provides some sort of validation.

I'm not sure how useful having using OVN with other drivers will be, and
that was my initial concern with doing ML2 vs. full plugin. With the HW
VTEP support in OVN+OVS, you can tie in physical devices this way. Anyways,
this is where we're at for now. Comments welcome, of course.

That was also kind of my point regarding the control plane bits provided
by ML2 which OVN does not need. Still, the fact that we do not use a
function does not make any harm.
Also i'm not sure if OVN needs at all a type manager. If not, we can
always implement a no-op type manager, I guess.

Salvatore

Thanks,
Kyle

[1] https://github.com/stackforge/networking-ovn

On Mon, Feb 23, 2015 at 4:09 PM, Kevin Benton blak111@gmail.com wrote:

I want to emphasize Salvatore's last two points a bit more. If you go
with a monolithic plugin, you eliminate the possibility of heterogenous
deployments.

One example of this that is common now is having the current OVS driver
responsible for setting up the vswitch and then having a ToR driver (e.g.
Big Switch, Arista, etc) responsible for setting up the fabric.
Additionally, there is a separate L3 plugin (e.g. the reference one,
Vyatta, etc) for providing routing.

I suppose with an overlay it's easier to take the route that you don't
want to be compatible with other networking stuff at the Neutron layer
(e.g. integration with the 3rd parties is orchestrated somewhere else). In
that case, the above scenario wouldn't make much sense to support, but it's
worth keeping in mind.

On Mon, Feb 23, 2015 at 10:28 AM, Salvatore Orlando <
sorlando@nicira.com> wrote:

I think there are a few factors which influence the ML2 driver vs
"monolithic" plugin debate, and they mostly depend on OVN rather than
Neutron.
From a Neutron perspective both plugins and drivers (as long at they
live in their own tree) will be supported in the foreseeable future. If a
ML2 mech driver is not the best option for OVN that would be ok - I don't
think the Neutron community advices development of a ML2 driver as the
preferred way for integrating with new backends.

The ML2 framework provides a long list of benefits that mechanism
driver developer can leverage.
Among those:
- The ability of leveraging Type drivers which relieves driver
developers from dealing with network segment allocation
- Post-commit and (for most operations) pre-commit hooks for
performing operation on the backend
- The ability to leverage some of the features offered by Neutron's
built-in control-plane such as L2-population
- A flexible mechanism for enabling driver-specific API extensions
- Promotes modular development and integration with higher-layer
services, such as L3. For instance OVN could provide the L2 support for
Neutron's built-in L3 control plane
- The (potential afaict) ability of interacting with other mechanism
driver such as those operating on physical appliances on the data center
-

In my opinion OVN developers should look at ML2 benefits, and check
which ones apply to this specific platform. I'd say that if there are 1 or
2 checks in the above list, maybe it would be the case to look at
developing a ML2 mechanism driver, and perhaps a L3 service plugin.
It is worth nothing that ML2, thanks to its type and mechanism driver
provides also some control plane capabilities. If those capabilities are
however on OVN's roadmap it might be instead worth looking at a
"monolithic" plugin, which can also be easily implemented by inheriting
from neutron.db.dbbaseplugin_v2.NeutronDbPluginV2, and then adding all
the python mixins for the extensions the plugin needs to support.

Salvatore

On 23 February 2015 at 18:32, Ben Pfaff blp@nicira.com wrote:

[branching off a discussion on ovs-dev at this point:
http://openvswitch.org/pipermail/dev/2015-February/051609.html]

On Fri, Feb 20, 2015 at 6:56 PM, Kyle Mestery mestery@mestery.com
wrote:

One thing to keep in mind, this ties somewhat into my response to
Russell
earlier on the decision around ML2 vs. core plugin. If we do ML2,
there are
type drivers for VLAN, VXLAN, and GRE tunnels. There is no
TypeDriver for
STT tunnels upstream now. It's just an item we need on the TODO
list if we
go down the STT tunnel path.

It was suggested to me off-list that this part of the discussion
should be on
openstack-dev, so here it is ;-)


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Kevin Benton


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Kevin Benton


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Feb 24, 2015 by Salvatore_Orlando (12,280 points)   2 5 8
0 votes

Not quite. Two segments with different segmentation types can just co-exist
'for free' right now. There is no automated encapsulation translator thing
that connects them together at this time. There is of course the question
of whether or not that part will be merged anytime soon, but that's a
different discussion.

On Tue, Feb 24, 2015 at 1:47 AM, Salvatore Orlando sorlando@nicira.com
wrote:

On 24 February 2015 at 10:36, Kevin Benton blak111@gmail.com wrote:

Even ignoring integration with other VXLAN based drivers inside of a
segment, using ML2 can allow someone to run a network with a mix of
segments using different segmentation types. As long as the OVN driver
understands which ports it is capable of binding, it can coexist with other
drivers and allow heterogenous setups 'for free'.

It seems you're suggesting that ML2 is now able to integrate heterogenous
segments even when the drivers interfacing with their respective backends
ignore each other. In other words I can have a network with a segment
speaking VLANs and managed by driver "A", another segment speaking VxLAN
managed by driver "B", with ML2 providing you "for free" connectivity
between these two segment, thus achieving the heterogenous setup you were
mentioning.

I was unaware that such support was now available in ML2. In that case any
non-ML2 choice is probably a no brainer.

On Tue, Feb 24, 2015 at 1:19 AM, Salvatore Orlando sorlando@nicira.com
wrote:

On 24 February 2015 at 01:34, Kyle Mestery mestery@mestery.com wrote:

Russel and I have already merged the initial ML2 skeleton driver [1].

The thinking is that we can always revert to a non-ML2 driver if needed.
>

If nothing else an authoritative decision on a design direction saves us
the hassle of going through iterations and discussions.
The integration through ML2 is definitely viable. My opinion however is
that since OVN implements a full control plane, the control plane bits
provided by ML2 are not necessary, and a plugin which provides only
management layer capabilities might be the best solution. Note: this does
not mean it has to be monolithic. We can still do L3 with a service plugin.
However, since the same kind of approach has been adopted for ODL I
guess this provides some sort of validation.

I'm not sure how useful having using OVN with other drivers will be,
and that was my initial concern with doing ML2 vs. full plugin. With the HW
VTEP support in OVN+OVS, you can tie in physical devices this way. Anyways,
this is where we're at for now. Comments welcome, of course.

That was also kind of my point regarding the control plane bits provided
by ML2 which OVN does not need. Still, the fact that we do not use a
function does not make any harm.
Also i'm not sure if OVN needs at all a type manager. If not, we can
always implement a no-op type manager, I guess.

Salvatore

Thanks,
Kyle

[1] https://github.com/stackforge/networking-ovn

On Mon, Feb 23, 2015 at 4:09 PM, Kevin Benton blak111@gmail.com
wrote:

I want to emphasize Salvatore's last two points a bit more. If you go
with a monolithic plugin, you eliminate the possibility of heterogenous
deployments.

One example of this that is common now is having the current OVS
driver responsible for setting up the vswitch and then having a ToR driver
(e.g. Big Switch, Arista, etc) responsible for setting up the fabric.
Additionally, there is a separate L3 plugin (e.g. the reference one,
Vyatta, etc) for providing routing.

I suppose with an overlay it's easier to take the route that you don't
want to be compatible with other networking stuff at the Neutron layer
(e.g. integration with the 3rd parties is orchestrated somewhere else). In
that case, the above scenario wouldn't make much sense to support, but it's
worth keeping in mind.

On Mon, Feb 23, 2015 at 10:28 AM, Salvatore Orlando <
sorlando@nicira.com> wrote:

I think there are a few factors which influence the ML2 driver vs
"monolithic" plugin debate, and they mostly depend on OVN rather than
Neutron.
From a Neutron perspective both plugins and drivers (as long at they
live in their own tree) will be supported in the foreseeable future. If a
ML2 mech driver is not the best option for OVN that would be ok - I don't
think the Neutron community advices development of a ML2 driver as the
preferred way for integrating with new backends.

The ML2 framework provides a long list of benefits that mechanism
driver developer can leverage.
Among those:
- The ability of leveraging Type drivers which relieves driver
developers from dealing with network segment allocation
- Post-commit and (for most operations) pre-commit hooks for
performing operation on the backend
- The ability to leverage some of the features offered by Neutron's
built-in control-plane such as L2-population
- A flexible mechanism for enabling driver-specific API extensions
- Promotes modular development and integration with higher-layer
services, such as L3. For instance OVN could provide the L2 support for
Neutron's built-in L3 control plane
- The (potential afaict) ability of interacting with other mechanism
driver such as those operating on physical appliances on the data center
-

In my opinion OVN developers should look at ML2 benefits, and check
which ones apply to this specific platform. I'd say that if there are 1 or
2 checks in the above list, maybe it would be the case to look at
developing a ML2 mechanism driver, and perhaps a L3 service plugin.
It is worth nothing that ML2, thanks to its type and mechanism driver
provides also some control plane capabilities. If those capabilities are
however on OVN's roadmap it might be instead worth looking at a
"monolithic" plugin, which can also be easily implemented by inheriting
from neutron.db.dbbaseplugin_v2.NeutronDbPluginV2, and then adding all
the python mixins for the extensions the plugin needs to support.

Salvatore

On 23 February 2015 at 18:32, Ben Pfaff blp@nicira.com wrote:

[branching off a discussion on ovs-dev at this point:
http://openvswitch.org/pipermail/dev/2015-February/051609.html]

On Fri, Feb 20, 2015 at 6:56 PM, Kyle Mestery mestery@mestery.com
wrote:

One thing to keep in mind, this ties somewhat into my response to
Russell
earlier on the decision around ML2 vs. core plugin. If we do ML2,
there are
type drivers for VLAN, VXLAN, and GRE tunnels. There is no
TypeDriver for
STT tunnels upstream now. It's just an item we need on the TODO
list if we
go down the STT tunnel path.

It was suggested to me off-list that this part of the discussion
should be on
openstack-dev, so here it is ;-)


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Kevin Benton


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Kevin Benton


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Kevin Benton


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Feb 24, 2015 by Kevin_Benton (24,800 points)   3 5 5
0 votes

On Tue, Feb 24, 2015 at 3:19 AM, Salvatore Orlando sorlando@nicira.com
wrote:

On 24 February 2015 at 01:34, Kyle Mestery mestery@mestery.com wrote:

Russel and I have already merged the initial ML2 skeleton driver [1].

The thinking is that we can always revert to a non-ML2 driver if needed.
>

If nothing else an authoritative decision on a design direction saves us
the hassle of going through iterations and discussions.
The integration through ML2 is definitely viable. My opinion however is
that since OVN implements a full control plane, the control plane bits
provided by ML2 are not necessary, and a plugin which provides only
management layer capabilities might be the best solution. Note: this does
not mean it has to be monolithic. We can still do L3 with a service plugin.
However, since the same kind of approach has been adopted for ODL I guess
this provides some sort of validation.

To be honest, after thinking about this last night, I'm now leaning towards
doing this as a full plugin. I don't really envision OVN running with other
plugins, as OVN is implementing it's own control plane, as you say. So the
value of using ML2 is quesitonable.

I'm not sure how useful having using OVN with other drivers will be, and

that was my initial concern with doing ML2 vs. full plugin. With the HW
VTEP support in OVN+OVS, you can tie in physical devices this way. Anyways,
this is where we're at for now. Comments welcome, of course.

That was also kind of my point regarding the control plane bits provided
by ML2 which OVN does not need. Still, the fact that we do not use a
function does not make any harm.
Also i'm not sure if OVN needs at all a type manager. If not, we can
always implement a no-op type manager, I guess.

See above. I'd like to propose we move OVN to a full plugin instead of an
ML2 MechanismDriver.

Kyle

Salvatore

Thanks,
Kyle

[1] https://github.com/stackforge/networking-ovn

On Mon, Feb 23, 2015 at 4:09 PM, Kevin Benton blak111@gmail.com wrote:

I want to emphasize Salvatore's last two points a bit more. If you go
with a monolithic plugin, you eliminate the possibility of heterogenous
deployments.

One example of this that is common now is having the current OVS driver
responsible for setting up the vswitch and then having a ToR driver (e.g.
Big Switch, Arista, etc) responsible for setting up the fabric.
Additionally, there is a separate L3 plugin (e.g. the reference one,
Vyatta, etc) for providing routing.

I suppose with an overlay it's easier to take the route that you don't
want to be compatible with other networking stuff at the Neutron layer
(e.g. integration with the 3rd parties is orchestrated somewhere else). In
that case, the above scenario wouldn't make much sense to support, but it's
worth keeping in mind.

On Mon, Feb 23, 2015 at 10:28 AM, Salvatore Orlando <sorlando@nicira.com

wrote:

I think there are a few factors which influence the ML2 driver vs
"monolithic" plugin debate, and they mostly depend on OVN rather than
Neutron.
From a Neutron perspective both plugins and drivers (as long at they
live in their own tree) will be supported in the foreseeable future. If a
ML2 mech driver is not the best option for OVN that would be ok - I don't
think the Neutron community advices development of a ML2 driver as the
preferred way for integrating with new backends.

The ML2 framework provides a long list of benefits that mechanism
driver developer can leverage.
Among those:
- The ability of leveraging Type drivers which relieves driver
developers from dealing with network segment allocation
- Post-commit and (for most operations) pre-commit hooks for performing
operation on the backend
- The ability to leverage some of the features offered by Neutron's
built-in control-plane such as L2-population
- A flexible mechanism for enabling driver-specific API extensions
- Promotes modular development and integration with higher-layer
services, such as L3. For instance OVN could provide the L2 support for
Neutron's built-in L3 control plane
- The (potential afaict) ability of interacting with other mechanism
driver such as those operating on physical appliances on the data center
-

In my opinion OVN developers should look at ML2 benefits, and check
which ones apply to this specific platform. I'd say that if there are 1 or
2 checks in the above list, maybe it would be the case to look at
developing a ML2 mechanism driver, and perhaps a L3 service plugin.
It is worth nothing that ML2, thanks to its type and mechanism driver
provides also some control plane capabilities. If those capabilities are
however on OVN's roadmap it might be instead worth looking at a
"monolithic" plugin, which can also be easily implemented by inheriting
from neutron.db.dbbaseplugin_v2.NeutronDbPluginV2, and then adding all
the python mixins for the extensions the plugin needs to support.

Salvatore

On 23 February 2015 at 18:32, Ben Pfaff blp@nicira.com wrote:

[branching off a discussion on ovs-dev at this point:
http://openvswitch.org/pipermail/dev/2015-February/051609.html]

On Fri, Feb 20, 2015 at 6:56 PM, Kyle Mestery mestery@mestery.com
wrote:

One thing to keep in mind, this ties somewhat into my response to
Russell
earlier on the decision around ML2 vs. core plugin. If we do ML2,
there are
type drivers for VLAN, VXLAN, and GRE tunnels. There is no
TypeDriver for
STT tunnels upstream now. It's just an item we need on the TODO list
if we
go down the STT tunnel path.

It was suggested to me off-list that this part of the discussion
should be on
openstack-dev, so here it is ;-)


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Kevin Benton


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Feb 24, 2015 by Kyle_Mestery (16,960 points)   3 3 6
0 votes

OVN implementing it's own control plane isn't a good reason to make it a
monolithic plugin. Many of the ML2 drivers are for technologies with their
own control plane.

Going with the monolithic plugin only makes sense if you are certain that
you never want interoperability with other technologies at the Neutron
level. Instead of ruling that out this early, why not make it as an ML2
driver and then change to a monolithic plugin if you run into some
fundamental issue with ML2?
On Feb 24, 2015 8:16 AM, "Kyle Mestery" mestery@mestery.com wrote:

On Tue, Feb 24, 2015 at 3:19 AM, Salvatore Orlando sorlando@nicira.com
wrote:

On 24 February 2015 at 01:34, Kyle Mestery mestery@mestery.com wrote:

Russel and I have already merged the initial ML2 skeleton driver [1].

The thinking is that we can always revert to a non-ML2 driver if needed.
>

If nothing else an authoritative decision on a design direction saves us
the hassle of going through iterations and discussions.
The integration through ML2 is definitely viable. My opinion however is
that since OVN implements a full control plane, the control plane bits
provided by ML2 are not necessary, and a plugin which provides only
management layer capabilities might be the best solution. Note: this does
not mean it has to be monolithic. We can still do L3 with a service plugin.
However, since the same kind of approach has been adopted for ODL I guess
this provides some sort of validation.

To be honest, after thinking about this last night, I'm now leaning
towards doing this as a full plugin. I don't really envision OVN running
with other plugins, as OVN is implementing it's own control plane, as you
say. So the value of using ML2 is quesitonable.

I'm not sure how useful having using OVN with other drivers will be, and

that was my initial concern with doing ML2 vs. full plugin. With the HW
VTEP support in OVN+OVS, you can tie in physical devices this way. Anyways,
this is where we're at for now. Comments welcome, of course.

That was also kind of my point regarding the control plane bits provided
by ML2 which OVN does not need. Still, the fact that we do not use a
function does not make any harm.
Also i'm not sure if OVN needs at all a type manager. If not, we can
always implement a no-op type manager, I guess.

See above. I'd like to propose we move OVN to a full plugin instead of an
ML2 MechanismDriver.

Kyle

Salvatore

Thanks,
Kyle

[1] https://github.com/stackforge/networking-ovn

On Mon, Feb 23, 2015 at 4:09 PM, Kevin Benton blak111@gmail.com wrote:

I want to emphasize Salvatore's last two points a bit more. If you go
with a monolithic plugin, you eliminate the possibility of heterogenous
deployments.

One example of this that is common now is having the current OVS driver
responsible for setting up the vswitch and then having a ToR driver (e.g.
Big Switch, Arista, etc) responsible for setting up the fabric.
Additionally, there is a separate L3 plugin (e.g. the reference one,
Vyatta, etc) for providing routing.

I suppose with an overlay it's easier to take the route that you don't
want to be compatible with other networking stuff at the Neutron layer
(e.g. integration with the 3rd parties is orchestrated somewhere else). In
that case, the above scenario wouldn't make much sense to support, but it's
worth keeping in mind.

On Mon, Feb 23, 2015 at 10:28 AM, Salvatore Orlando <
sorlando@nicira.com> wrote:

I think there are a few factors which influence the ML2 driver vs
"monolithic" plugin debate, and they mostly depend on OVN rather than
Neutron.
From a Neutron perspective both plugins and drivers (as long at they
live in their own tree) will be supported in the foreseeable future. If a
ML2 mech driver is not the best option for OVN that would be ok - I don't
think the Neutron community advices development of a ML2 driver as the
preferred way for integrating with new backends.

The ML2 framework provides a long list of benefits that mechanism
driver developer can leverage.
Among those:
- The ability of leveraging Type drivers which relieves driver
developers from dealing with network segment allocation
- Post-commit and (for most operations) pre-commit hooks for
performing operation on the backend
- The ability to leverage some of the features offered by Neutron's
built-in control-plane such as L2-population
- A flexible mechanism for enabling driver-specific API extensions
- Promotes modular development and integration with higher-layer
services, such as L3. For instance OVN could provide the L2 support for
Neutron's built-in L3 control plane
- The (potential afaict) ability of interacting with other mechanism
driver such as those operating on physical appliances on the data center
-

In my opinion OVN developers should look at ML2 benefits, and check
which ones apply to this specific platform. I'd say that if there are 1 or
2 checks in the above list, maybe it would be the case to look at
developing a ML2 mechanism driver, and perhaps a L3 service plugin.
It is worth nothing that ML2, thanks to its type and mechanism driver
provides also some control plane capabilities. If those capabilities are
however on OVN's roadmap it might be instead worth looking at a
"monolithic" plugin, which can also be easily implemented by inheriting
from neutron.db.dbbaseplugin_v2.NeutronDbPluginV2, and then adding all
the python mixins for the extensions the plugin needs to support.

Salvatore

On 23 February 2015 at 18:32, Ben Pfaff blp@nicira.com wrote:

[branching off a discussion on ovs-dev at this point:
http://openvswitch.org/pipermail/dev/2015-February/051609.html]

On Fri, Feb 20, 2015 at 6:56 PM, Kyle Mestery mestery@mestery.com
wrote:

One thing to keep in mind, this ties somewhat into my response to
Russell
earlier on the decision around ML2 vs. core plugin. If we do ML2,
there are
type drivers for VLAN, VXLAN, and GRE tunnels. There is no
TypeDriver for
STT tunnels upstream now. It's just an item we need on the TODO
list if we
go down the STT tunnel path.

It was suggested to me off-list that this part of the discussion
should be on
openstack-dev, so here it is ;-)


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Kevin Benton


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Feb 24, 2015 by Kevin_Benton (24,800 points)   3 5 5
0 votes

Kyle, What happened to the long-term potential goal of ML2 driver APIs
becoming neutron's core APIs? Do we really want to encourage new
monolithic plugins?

ML2 is not a control plane - its really just an integration point for
control planes. Although co-existence of multiple mechanism drivers is
possible, and sometimes very useful, the single-driver case is fully
supported. Even with hierarchical bindings, its not really ML2 that
controls what happens - its the drivers within the framework. I don't
think ML2 really limits what drivers can do, as long as a virtual
network can be described as a set of static and possibly dynamic network
segments. ML2 is intended to impose as few constraints on drivers as
possible.

My recommendation would be to implement an ML2 mechanism driver for OVN,
along with any needed new type drivers or extension drivers. I believe
this will result in a lot less new code to write and maintain.

Also, keep in mind that even if multiple driver co-existence doesn't
sound immediately useful, there are several potential use cases to
consider. One is that it allows new technology to be introduced into an
existing cloud alongside what previously existed. Migration from one ML2
driver to another may be a lot simpler (and/or flexible) than migration
from one plugin to another. Another is that additional drivers can
support special cases, such as bare metal, appliances, etc..

-Bob

On 2/24/15 11:11 AM, Kyle Mestery wrote:
On Tue, Feb 24, 2015 at 3:19 AM, Salvatore Orlando
<sorlando@nicira.com sorlando@nicira.com> wrote:

On 24 February 2015 at 01:34, Kyle Mestery <mestery@mestery.com
<mailto:mestery@mestery.com>> wrote:

    Russel and I have already merged the initial ML2 skeleton
    driver [1].

    The thinking is that we can always revert to a non-ML2 driver
    if needed.


If nothing else an authoritative decision on a design direction
saves us the hassle of going through iterations and discussions.
The integration through ML2 is definitely viable. My opinion
however is that since OVN implements a full control plane, the
control plane bits provided by ML2 are not necessary, and a plugin
which provides only management layer capabilities might be the
best solution. Note: this does not mean it has to be monolithic.
We can still do L3 with a service plugin.
However, since the same kind of approach has been adopted for ODL
I guess this provides some sort of validation.

To be honest, after thinking about this last night, I'm now leaning
towards doing this as a full plugin. I don't really envision OVN
running with other plugins, as OVN is implementing it's own control
plane, as you say. So the value of using ML2 is quesitonable.

    I'm not sure how useful having using OVN with other drivers
    will be, and that was my initial concern with doing ML2 vs.
    full plugin. With the HW VTEP support in OVN+OVS, you can tie
    in physical devices this way. Anyways, this is where we're at
    for now. Comments welcome, of course.


That was also kind of my point regarding the control plane bits
provided by ML2 which OVN does not need. Still, the fact that we
do not use a function does not make any harm.
Also i'm not sure if OVN needs at all a type manager. If not, we
can always implement a no-op type manager, I guess.

See above. I'd like to propose we move OVN to a full plugin instead of
an ML2 MechanismDriver.

Kyle

Salvatore


    Thanks,
    Kyle

    [1] https://github.com/stackforge/networking-ovn

    On Mon, Feb 23, 2015 at 4:09 PM, Kevin Benton
    <blak111@gmail.com <mailto:blak111@gmail.com>> wrote:

        I want to emphasize Salvatore's last two points a bit
        more. If you go with a monolithic plugin, you eliminate
        the possibility of heterogenous deployments.

        One example of this that is common now is having the
        current OVS driver responsible for setting up the vswitch
        and then having a ToR driver (e.g. Big Switch, Arista,
        etc) responsible for setting up the fabric. Additionally,
        there is a separate L3 plugin (e.g. the reference one,
        Vyatta, etc) for providing routing.

        I suppose with an overlay it's easier to take the route
        that you don't want to be compatible with other networking
        stuff at the Neutron layer (e.g. integration with the 3rd
        parties is orchestrated somewhere else). In that case, the
        above scenario wouldn't make much sense to support, but
        it's worth keeping in mind.

        On Mon, Feb 23, 2015 at 10:28 AM, Salvatore Orlando
        <sorlando@nicira.com <mailto:sorlando@nicira.com>> wrote:

            I think there are a few factors which influence the
            ML2 driver vs "monolithic" plugin debate, and they
            mostly depend on OVN rather than Neutron.
            From a Neutron perspective both plugins and drivers
            (as long at they live in their own tree) will be
            supported in the foreseeable future. If a ML2 mech
            driver is not the best option for OVN that would be ok
            - I don't think the Neutron community advices
            development of a ML2 driver as the preferred way for
            integrating with new backends.

            The ML2 framework provides a long list of benefits
            that mechanism driver developer can leverage.
            Among those:
            - The ability of leveraging Type drivers which
            relieves driver developers from dealing with network
            segment allocation
            - Post-commit and (for most operations) pre-commit
            hooks for performing operation on the backend
            - The ability to leverage some of the features offered
            by Neutron's built-in control-plane such as L2-population
            - A flexible mechanism for enabling driver-specific
            API extensions
            - Promotes modular development and integration with
            higher-layer services, such as L3. For instance OVN
            could provide the L2 support for Neutron's built-in L3
            control plane
            - The (potential afaict) ability of interacting with
            other mechanism driver such as those operating on
            physical appliances on the data center
            - <add your benefit here>

            In my opinion OVN developers should look at ML2
            benefits, and check which ones apply to this specific
            platform. I'd say that if there are 1 or 2 checks in
            the above list, maybe it would be the case to look at
            developing a ML2 mechanism driver, and perhaps a L3
            service plugin.
            It is worth nothing that ML2, thanks to its type and
            mechanism driver provides also some control plane
            capabilities. If those capabilities are however on
            OVN's roadmap it might be instead worth looking at a
            "monolithic" plugin, which can also be easily
            implemented by inheriting from
            neutron.db.db_base_plugin_v2.NeutronDbPluginV2, and
            then adding all the python mixins for the extensions
            the plugin needs to support.

            Salvatore


            On 23 February 2015 at 18:32, Ben Pfaff
            <blp@nicira.com <mailto:blp@nicira.com>> wrote:

                [branching off a discussion on ovs-dev at this point:
                http://openvswitch.org/pipermail/dev/2015-February/051609.html]

                On Fri, Feb 20, 2015 at 6:56 PM, Kyle Mestery
                <mestery@mestery.com <mailto:mestery@mestery.com>>
                wrote:
                > One thing to keep in mind, this ties somewhat
                into my response to Russell
                > earlier on the decision around ML2 vs. core
                plugin. If we do ML2, there are
                > type drivers for VLAN, VXLAN, and GRE tunnels.
                There is no TypeDriver for
                > STT tunnels upstream now. It's just an item we
                need on the TODO list if we
                > go down the STT tunnel path.

                It was suggested to me off-list that this part of
                the discussion should be on
                openstack-dev, so here it is ;-)

                __________________________________________________________________________
                OpenStack Development Mailing List (not for usage
                questions)
                Unsubscribe:
                OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
                
                http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



            __________________________________________________________________________
            OpenStack Development Mailing List (not for usage
            questions)
            Unsubscribe:
            OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
            
            http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




        -- 
        Kevin Benton

        __________________________________________________________________________
        OpenStack Development Mailing List (not for usage questions)
        Unsubscribe:
        OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
        
        http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



    __________________________________________________________________________
    OpenStack Development Mailing List (not for usage questions)
    Unsubscribe:
    OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
    
    http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Feb 24, 2015 by Robert_Kukura (1,620 points)   1 2
...