Yes, looks like option 4 is the best. We need an abstraction layer between extensions and agents, to make sure API makes sense for all AMQP based agents.
Common agent framework that I think Sean side looks at [1] could partially define that agent interface for us. [1]: https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:master+topic:lb_common_agent_experiment,n,z Ihar > On 25 Sep 2015, at 11:12, Miguel Angel Ajo <mangel...@redhat.com> wrote: > > I didn't finish reading it, and was thinking about the same thing exactly. > > IMHO option 4th is the best. So we will be able to provide an interface where > stability > is controlled, where we can deprecate things in a controlled manner, and we > know what we > support and what we don't. > > Do you have a rough idea of what operations you may need to do? > > Please bear in mind, the extension interface will be available from different > agent types > (OVS, SR-IOV, [eventually LB]), so this interface you're talking about could > also serve as > a translation driver for the agents (where the translation is possible), I > totally understand > that most extensions are specific agent bound, and we must be able to identify > the agent we're serving back exactly. > > > Best regards, > Miguel Ángel Ajo > > Kevin Benton 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 >>> >>> >> >> >> __________________________________________________________________________ >> 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 >
signature.asc
Description: Message signed with OpenPGP using GPGMail
__________________________________________________________________________ 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
