<div dir="ltr">I think we're speculating a lot about what would be best for OVN whereas we should probably just expose pro and cons of ML2 drivers vs standalone plugin (as I said earlier on indeed it does not necessarily imply monolithic *)<div><br></div><div>I reckon the job of the Neutron community is to provide a full picture to OVN developers - so that they could make a call on the integration strategy that best suits them.</div><div>On the other hand, if we're planning to commit to a model where ML2 is not anymore a plugin but the interface with the API layer, then any choice which is not a ML2 driver does not make any sense. Personally I'm not sure we ever want to do that, at least not in the near/medium term, but I'm one and hardly representative of the developer/operator communities.</div><div><br></div><div>Salvatore<br><div><br></div><div><br></div><div>* In particular with the advanced service split out the term monolithic simply does not mean anything anymore.</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 24 February 2015 at 17:48, Robert Kukura <span dir="ltr"><<a href="mailto:kukura@noironetworks.com" target="_blank">kukura@noironetworks.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
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?<br>
<br>
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.<br>
<br>
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.<br>
<br>
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..<br>
<br>
-Bob<div><div class="h5"><br>
<br>
<div>On 2/24/15 11:11 AM, Kyle Mestery
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">On Tue, Feb 24, 2015 at 3:19 AM,
Salvatore Orlando <span dir="ltr"><<a href="mailto:sorlando@nicira.com" target="_blank">sorlando@nicira.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote"><span>On 24 February
2015 at 01:34, Kyle Mestery <span dir="ltr"><<a href="mailto:mestery@mestery.com" target="_blank">mestery@mestery.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div>
<div>Russel and I have already merged the
initial ML2 skeleton driver [1].</div>
</div>
</div>
</blockquote>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div>
<div>The thinking is that we can always
revert to a non-ML2 driver if needed. </div>
</div>
</div>
</blockquote>
<div><br>
</div>
</span>
<div>If nothing else an authoritative decision on a
design direction saves us the hassle of going
through iterations and discussions.</div>
<div>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.<br>
</div>
<div>However, since the same kind of approach has
been adopted for ODL I guess this provides some
sort of validation.</div>
<span>
<div> <br>
</div>
</span></div>
</div>
</div>
</blockquote>
<div>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.<br>
<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote"><span>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div>
<div>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.<br>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
</span>
<div>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. </div>
<div>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.</div>
<span><font color="#888888">
<div><br>
</div>
</font></span></div>
</div>
</div>
</blockquote>
<div>See above. I'd like to propose we move OVN to a full
plugin instead of an ML2 MechanismDriver.<br>
<br>
</div>
<div>Kyle<br>
<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote"><span><font color="#888888">
<div>Salvatore</div>
</font></span>
<div>
<div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div>
<div><br>
</div>
Thanks,<br>
</div>
Kyle<br>
<br>
[1] <a href="https://github.com/stackforge/networking-ovn" target="_blank">https://github.com/stackforge/networking-ovn</a><br>
</div>
<div>
<div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Mon, Feb 23,
2015 at 4:09 PM, Kevin Benton <span dir="ltr"><<a href="mailto:blak111@gmail.com" target="_blank">blak111@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">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.
<div><br>
</div>
<div>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.
<div><br>
</div>
<div>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.</div>
</div>
</div>
<div class="gmail_extra">
<div>
<div><br>
<div class="gmail_quote">On
Mon, Feb 23, 2015 at 10:28
AM, Salvatore Orlando <span dir="ltr"><<a href="mailto:sorlando@nicira.com" target="_blank">sorlando@nicira.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">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.
<div>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.<br>
</div>
<div><br>
</div>
<div>The ML2 framework
provides a long list
of benefits that
mechanism driver
developer can
leverage.</div>
<div>Among those:</div>
<div>- The ability of
leveraging Type
drivers which relieves
driver developers from
dealing with network
segment allocation</div>
<div>- Post-commit and
(for most operations)
pre-commit hooks for
performing operation
on the backend</div>
<div>- The ability to
leverage some of the
features offered by
Neutron's built-in
control-plane such as
L2-population</div>
<div>- A flexible
mechanism for enabling
driver-specific API
extensions</div>
<div>- 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</div>
<div>- The (potential
afaict) ability of
interacting with other
mechanism driver such
as those operating on
physical appliances on
the data center</div>
<div>- <add your
benefit here></div>
<div><br>
</div>
<div>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.</div>
<div>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.<span><font color="#888888"><br>
</font></span></div>
<span><font color="#888888">
<div><br>
</div>
<div>Salvatore<br>
</div>
</font></span>
<div>
<div>
<div><br>
<div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On
23 February
2015 at 18:32,
Ben Pfaff <span dir="ltr"><<a href="mailto:blp@nicira.com" target="_blank">blp@nicira.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">[branching
off a
discussion on
ovs-dev at
this point:<br>
<a href="http://openvswitch.org/pipermail/dev/2015-February/051609.html" target="_blank">http://openvswitch.org/pipermail/dev/2015-February/051609.html</a>]<br>
<br>
On Fri, Feb
20, 2015 at
6:56 PM, Kyle
Mestery <<a href="mailto:mestery@mestery.com" target="_blank">mestery@mestery.com</a>>
wrote:<br>
> One thing
to keep in
mind, this
ties somewhat
into my
response to
Russell<br>
> earlier
on the
decision
around ML2 vs.
core plugin.
If we do ML2,
there are<br>
> type
drivers for
VLAN, VXLAN,
and GRE
tunnels. There
is no
TypeDriver for<br>
> STT
tunnels
upstream now.
It's just an
item we need
on the TODO
list if we<br>
> go down
the STT tunnel
path.<br>
<br>
It was
suggested to
me off-list
that this part
of the
discussion
should be on<br>
openstack-dev,
so here it is
;-)<br>
<br>
__________________________________________________________________________<br>
OpenStack
Development
Mailing List
(not for usage
questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
__________________________________________________________________________<br>
OpenStack Development
Mailing List (not for
usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
</div>
</div>
<span><font color="#888888">-- <br>
<div>
<div>Kevin Benton</div>
</div>
</font></span></div>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List
(not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for
usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
</blockquote>
</div>
</div>
</div>
<br>
</div>
</div>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage
questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</div></div></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>