Open Stack

I see Kyle's point that this is not something in-scope for liberty at this
stage.

However, on the other hand I would rather avoid having multiple agents on
the compute node performing various tasks in an un-coordinated way (well,
actually relying on neutron-server coordination).

QoS is an example, but what Miguel is doing for QoS applies, for instance,
to security groups and allowed address pairs processing. Even if probably
Mohammad has more in mind a "modular" agent that is able to talk to
different data planes using a well-defined driver interface,  a similar
framework could be used for "augmenting" the capabilities of an agent as
Miguel mentions.

I would probably start with something for enabling the L2 agent to process
"features" such as QoS and security groups, working on the OVS agent, and
then in a second step abstract a driver interface for communicating with
the data plane. But I honestly do not know if this will keep the work too
"OVS-centric" and therefore won't play well with the current efforts to put
linux bridge on par with OVS in Neutron. For those question we should seek
an answer from our glorious reference control plane lieutenant, and perhaps
also from Sean Collins, who's coordinating efforts around linux bridge
parity.

Salvatore

On 22 June 2015 at 16:30, Miguel Angel Ajo <mangelajo at redhat.com> wrote:

>
>
> In the context of Quality of Service, we need to extend the L2 agents
> (SR-IOV,
> OVS and LB), and we didn't want to simply hijack the processing loop of
> the agents,
> but take a moment, and put together a Modular L2 design
>
> https://review.openstack.org/#/c/189723/
>
> If you find it reasonable to do it in this context so it can be reused for
> neutron
> in general later, please join the reviews.
>
> I'm not sure if Irena was involved on previous Modular L2 Agent design
> sessions.
>
>
> Best regards,
> Miguel Ángel.
>
>
> Mohammad Banikazemi wrote:
>
>
>
> During the last couple of ML2 group meetings, the subject of Modular L2
> Agents has come up again and I was tasked to bring up the subject to the
> attention of the larger community.
> We are aware of the ongoing efforts to improve the L2 agent(s) and the
> patches which are currently under review and those that got merged
> recently. The question is whether the Neutron community thinks the effort
> started (and suspended) a while ago around creating a modular L2 agent is
> worth pursuing at all and if yes, whether this is a good cycle to get that
> work possibly restarted.
>
> Best,
>
> Mohammad
> __________________________________________________________________________
> 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
>
>
>
>   Mohammad Banikazemi <mb at us.ibm.com>
>  21 Jun 2015 18:54 via Postbox
> <https://www.postbox-inc.com/?utm_source=email&utm_medium=sumlink&utm_campaign=reach>
>
> During the last couple of ML2 group meetings, the subject of Modular L2
> Agents has come up again and I was tasked to bring up the subject to the
> attention of the larger community.
> We are aware of the ongoing efforts to improve the L2 agent(s) and the
> patches which are currently under review and those that got merged
> recently. The question is whether the Neutron community thinks the effort
> started (and suspended) a while ago around creating a modular L2 agent is
> worth pursuing at all and if yes, whether this is a good cycle to get that
> work possibly restarted.
>
> Best,
>
> Mohammad
> __________________________________________________________________________
> 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/20150622/f47e11ac/attachment.html>