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
<sorla...@nicira.com <mailto:sorla...@nicira.com>> wrote:
On 24 February 2015 at 01:34, Kyle Mestery <mest...@mestery.com
<mailto:mest...@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
<blak...@gmail.com <mailto:blak...@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
<sorla...@nicira.com <mailto:sorla...@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
<b...@nicira.com <mailto:b...@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
<mest...@mestery.com <mailto:mest...@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-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
