Open Stack

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 <mangelajo at 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.morin at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150925/84be95e8/attachment.pgp>