Open Stack

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

> 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.
>
>
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 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
>>
>>
>
> __________________________________________________________________________
> 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/34ec767c/attachment.html>