[openstack-dev] [neutron] How could an L2 agent extension access agent methods ?

thomas.morin at orange.com thomas.morin at orange.com
Fri Sep 25 08:32:12 UTC 2015


Hi everyone,

(TL;DR: we would like an L2 agent extension to be able to call methods 
on the agent class, e.g. OVSAgent)

In the networking-bgpvpn project, we need the reference driver to 
interact with the ML2 openvswitch agent with new RPCs to allow 
exchanging information with the BGP VPN implementation running on the 
compute nodes. We also need the OVS agent to setup specific things on 
the OVS bridges for MPLS traffic.

To extend the agent behavior, we currently create a new agent by 
mimicking the main() in ovs_neutron_agent.py but instead of 
instantiating instantiate OVSAgent, with instantiate a class that 
overloads the OVSAgent class with the additional behavior we need [1] .

This is really not the ideal way of extending the agent, and we would 
prefer using the L2 agent extension framework [2].

Using the L2 agent extension framework would work, but only partially: 
it would easily allos us to register our RPC consumers, but not to let 
us access to some datastructures/methods of the agent that we need to 
use: setup_entry_for_arp_reply and local_vlan_map, access to the 
OVSBridge objects to manipulate OVS ports.

I've filled-in an RFE bug to track this issue [5].

We would like something like one of the following:
1) augment the L2 agent extension interface (AgentCoreResourceExtension) 
to give access to the agent object (and thus let the extension call 
methods of the agent) by giving the agent as a parameter of the 
initialize method [4]
2) augment the L2 agent extension interface (AgentCoreResourceExtension) 
to give access to the agent object (and thus let the extension call 
methods of the agent) by giving the agent as a parameter of a new 
setAgent method
3) augment the L2 agent extension interface (AgentCoreResourceExtension) 
to give access only to specific/chosen methods on the agent object, for 
instance by giving a dict as a parameter of the initialize method [4], 
whose keys would be method names, and values would be pointer to these 
methods on the agent object
4) define a new interface with methods to access things inside the 
agent, this interface would be implemented by an object instantiated by 
the agent, and that the agent would pass to the extension manager, thus 
allowing the extension manager to passe the object to an extension 
through the initialize method of AgentCoreResourceExtension [4]

Any feedback on these ideas...?
Of course any other idea is welcome...

For the sake of triggering reaction, the question could be rephrased as: 
if we submit a change doing (1) above, would it have a reasonable chance 
of merging ?

-Thomas

[1] 
https://github.com/openstack/networking-bgpvpn/blob/master/networking_bgpvpn/neutron/services/service_drivers/bagpipe/ovs_agent/ovs_bagpipe_neutron_agent.py
[2] https://review.openstack.org/#/c/195439/
[3] 
https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/openvswitch/agent/extension_drivers/qos_driver.py#L30
[4] 
https://github.com/openstack/neutron/blob/master/neutron/agent/l2/agent_extension.py#L28
[5] https://bugs.launchpad.net/neutron/+bug/1499637


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150925/b3a011e9/attachment.html>


More information about the OpenStack-dev mailing list