I would like to second Kevin. This can be done in a similar way as ML2 Plugin passed plugin_context to ML2 Extension Drivers: https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/driver_api.py#L910 .
BR, Irena On Fri, Sep 25, 2015 at 11:57 AM, Kevin Benton <blak...@gmail.com> wrote: > I think the 4th of the options you proposed would be the best. We don't > want to give agents direct access to the agent object or else we will run > the risk of breaking extensions all of the time during any kind of > reorganization or refactoring. Having a well defined API in between will > give us flexibility to move things around. > > On Fri, Sep 25, 2015 at 1:32 AM, <thomas.mo...@orange.com> wrote: > >> 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 >> >> > > > -- > Kevin Benton > > __________________________________________________________________________ > 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 > >
__________________________________________________________________________ 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
