Open Stack

On 24 February 2015 at 01:34, Kyle Mestery <mestery at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150224/8ae5511b/attachment-0001.html>