Open Stack

Kevin, Miguel,

I agree that (4) is what makes most sense.
(more below)

Miguel Angel Ajo :
> Do you have a rough idea of what operations you may need to do?

Right now, what bagpipe driver for networking-bgpvpn needs to interact 
with is:
- int_br OVSBridge (read-only)
- tun_br OVSBridge (add patch port, add flows)
- patch_int_ofport port number (read-only)
- local_vlan_map dict (read-only)
- setup_entry_for_arp_reply method (called to add static ARP entries)

> 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.

Yes, I do have this in mind, but what we've identified for now seems to 
be OVS specific.

-Thomas



> 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.


_________________________________________________________________________________________________________________________

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.