Open Stack

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 <blak111 at 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.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
>>
>>
>
>
> --
> Kevin Benton
>
> __________________________________________________________________________
> 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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150927/0d04c9bf/attachment.html>