Open Stack

>So why not agent based?

Maybe I have an experimental operating system that can't run python. Maybe
the RPC channel between compute nodes and Neutron doesn't satisfy certain
security criteria. Regardless of the reason, it doesn't matter because that
is an implementation detail that should be irrelevant to separate ML2
drivers.

l2pop should be concerned with tunnel endpoints and tunnel endpoints only.
Whether or not you're running a chunk of code responding to messages on an
RPC bus and sending heartbeats should not be Neutron's concern. It defeats
the purpose of ML2 if everything that can bind a port has to be running a
neutron RPC-compatible agent.

The l2pop functionality should become part of the tunnel type drivers and
the mechanism drivers should be able to provide the termination endpoints
for the tunnels using whatever mechanism it chooses. Agent-based drivers
can use the agent DB to do this and then the REST drivers can provide
whatever termination point they want. This solves the interoperability
problem and relaxes this tight coupling between vxlan and agents.


On Wed, Aug 27, 2014 at 1:09 AM, loy wolfe <loywolfe at gmail.com> wrote:

>
>
>
> On Wed, Aug 27, 2014 at 3:13 PM, Kevin Benton <blak111 at gmail.com> wrote:
>
>> Ports are bound in order of configured drivers so as long as the
>> OpenVswitch driver is put first in the list, it will bind the ports it can
>> and then ODL would bind the leftovers. [1][2] The only missing component is
>> that ODL doesn't look like it uses l2pop so establishing tunnels between
>> the OVS agents and the ODL-managed vswitches would be an issue that would
>> have to be handled via another process.
>>
>> Regardless, my original point is that the driver keeps the neutron
>> semantics and DB in tact. In my opinion, the lack of compatibility with
>> l2pop isn't an issue with the driver, but more of an issue with how l2pop
>> was designed. It's very tightly coupled to having agents managed by Neutron
>> via RPC, which shouldn't be necessary when it's primary purpose is to
>> establish endpoints for overlay tunnels.
>>
>
> So why not agent based? Neutron shouldn't be treated as just an resource
> storage, built-in backends naturally need things like l2pop and dvr for
> distributed dynamic topology control,  we couldn't say that something as a
> part was "tightly coupled".
>
> On the contrary, 3rd backends should adapt themselves to be integrated
> into Neutron as thin as they can, focusing on the backend device control
> but not re-implement core service logic duplicated with Neutron . BTW,
> Ofagent is a good example for this style.
>
>
>>
>>
>> 1.
>> https://github.com/openstack/neutron/blob/7f466c8730cfca13f2fb374c80d810929bb8cccc/neutron/plugins/ml2/drivers/mech_agent.py#L53
>> 2.
>> https://github.com/openstack/neutron/blob/7f466c8730cfca13f2fb374c80d810929bb8cccc/neutron/plugins/ml2/drivers/mechanism_odl.py#L326
>>
>>
>> On Tue, Aug 26, 2014 at 10:05 PM, loy wolfe <loywolfe at gmail.com> wrote:
>>
>>>
>>>
>>>
>>> On Wed, Aug 27, 2014 at 12:42 PM, Kevin Benton <blak111 at gmail.com>
>>> wrote:
>>>
>>>> >I think that "opensource" is not the only factor, it's about built-in
>>>> vs. 3rd backend. Built-in must be opensource, but opensource is not
>>>> necessarily built-in. By my thought, current OVS and linuxbridge are
>>>> built-in, but shim RESTful proxy for all kinds of sdn controller should be
>>>> 3rd, for they keep all virtual networking data model and service logic in
>>>> their own places, using Neutron API just as the NB shell (they can't even
>>>> co-work with built-in l2pop driver for vxlan/gre network type today).
>>>>
>>>>
>>>> I understand the point you are trying to make, but this blanket
>>>> statement about the data model of drivers/plugins with REST backends is
>>>> wrong. Look at the ODL mechanism driver for a counter-example.[1] The data
>>>> is still stored in Neutron and all of the semantics of the API are
>>>> maintained. The l2pop driver is to deal with decentralized overlays, so I'm
>>>> not sure how its interoperability with the ODL driver is relevant.
>>>>
>>>
>>> If we create a vxlan network,  then can we bind some ports to built-in
>>> ovs driver, and other ports to ODL driver? linux bridge agnet, ovs agent,
>>> ofagent can co-exist in the same vxlan network, under the common l2pop
>>> mechanism. By that scenery, I'm not sure whether ODL can just add to them
>>> in a heterogeneous multi-backend architecture , or work exclusively and
>>> have to take over all the functionality.
>>>
>>>
>>>>
>>>> 1.
>>>> https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/mechanism_odl.py
>>>>
>>>>
>>>>
>>>> On Tue, Aug 26, 2014 at 7:14 PM, loy wolfe <loywolfe at gmail.com> wrote:
>>>>
>>>>> Forwarded from other thread discussing about incubator:
>>>>>
>>>>> http://lists.openstack.org/pipermail/openstack-dev/2014-August/044135.html
>>>>>
>>>>>
>>>>>
>>>>>> Completely agree with this sentiment. Is there a crisp distinction
>>>>>> between a "vendor" plugin and an "open source" plugin though?
>>>>>>
>>>>>>
>>>>> I think that "opensource" is not the only factor, it's about built-in
>>>>> vs. 3rd backend. Built-in must be opensource, but opensource is not
>>>>> necessarily built-in. By my thought, current OVS and linuxbridge are
>>>>> built-in, but shim RESTful proxy for all kinds of sdn controller should be
>>>>> 3rd, for they keep all virtual networking data model and service logic in
>>>>> their own places, using Neutron API just as the NB shell (they can't even
>>>>> co-work with built-in l2pop driver for vxlan/gre network type today).
>>>>>
>>>>> As for the Snabb or DPDKOVS (they also plan to support official qemu
>>>>> vhost-user), or some other similar contributions, if one or two of them win
>>>>> in the war of this high performance userspace vswitch, and receive large
>>>>> common interest, then it may be accepted as built-in.
>>>>>
>>>>>
>>>>>
>>>>>> The Snabb NFV (http://snabb.co/nfv.html) driver superficially looks
>>>>>> like a vendor plugin but is actually completely open source. The
>>>>>> development is driven by end-user organisations who want to make the
>>>>>> standard upstream Neutron support their NFV use cases.
>>>>>>
>>>>>> We are looking for a good way to engage with the upstream community.
>>>>>> In this cycle we have found kindred spirits in the NFV subteam., but we did
>>>>>> not find a good way to engage with Neutron upstream (see
>>>>>> https://review.openstack.org/#/c/116476/). It would be wonderful if
>>>>>> there is a suitable process available for us to use in Kilo e.g. incubation.
>>>>>>
>>>>>> Cheers,
>>>>>> -Luke
>>>>>>
>>>>>> _______________________________________________
>>>>>> OpenStack-dev mailing list
>>>>>> OpenStack-dev at lists.openstack.org
>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> OpenStack-dev mailing list
>>>>> OpenStack-dev at lists.openstack.org
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Kevin Benton
>>>>
>>>> _______________________________________________
>>>> OpenStack-dev mailing list
>>>> OpenStack-dev at lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>>
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>>
>> --
>> Kevin Benton
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Kevin Benton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140827/8a08ea13/attachment-0001.html>