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.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
