Open Stack

On Wed, Feb 25, 2015 at 5:34 AM, Sukhdev Kapur <sukhdevkapur at gmail.com>
wrote:

> Folks,
>
> A great discussion. I am not expert at OVN, hence, want to ask a question.
> The answer may make a  case that it should probably be a ML2 driver as
> oppose to monolithic plugin.
>
> Say a customer want to deploy an OVN based solution and use HW devices
> from one vendor for L2 and L3 (e.g. Arista or Cisco), and want to use
> another vendor for services (e.g. F5 or A10) - how can that be supported?
>
> If OVN goes in as ML2 driver, I can then run ML2 and Service plugin to
> achieve above solution. For a monolithic plugin, don't I have an issue?
>
On the specifics of service plugins: service plugins and standalone plugins
can co-exist to provide a solution with advanced services from different
vendors. Some existing monolithic plugins (e.g. PLUMgrid) have blueprints
deployed using this approach.

>
> regards..
> -Sukhdev
>
>
> On Tue, Feb 24, 2015 at 8:58 AM, Salvatore Orlando <sorlando at nicira.com>
> wrote:
>
>> 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
>>>
>>>
>>
>> __________________________________________________________________________
>> 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/20150225/d0b0d1b2/attachment.html>