Open Stack

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 *)

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.
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.

Salvatore


* In particular with the advanced service split out the term monolithic
simply does not mean anything anymore.

On 24 February 2015 at 17:48, Robert Kukura <kukura at noironetworks.com>
wrote:

>  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 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
>>
>>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribehttp://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/4c1c143a/attachment.html>