Hi Irena,

Irena Berezovsky :
> 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.

Yes, this would be similar and could indeed be named agent_context .

However, contrarily to ML2 plugin which provides a context when calling most driver methods, I don't think that here we would need a context to be passed at each call of an AgentCoreResourceExtension, providing a interface to hook to the agent at initialize seems enough to me.

Thanks,

-Thomas



On Fri, Sep 25, 2015 at 11:57 AM, Kevin Benton <blak...@gmail.com <mailto: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
   <mailto: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://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://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


_________________________________________________________________________________________________________________________

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

Reply via email to