[openstack-dev] [neutron] How could an L2 agent extension access agent methods ?
thomas.morin at orange.com
thomas.morin at orange.com
Wed Sep 30 10:08:31 UTC 2015
Hi Ihar,
Ihar Hrachyshka :
>> 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)
>>
> Sounds very tightly coupled to OVS agent.
>
>>> 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.
> Indeed it does. Maybe you can try to define the needed pieces in high level actions, not internal objects you need to access to. Like ‘- connect endpoint X to Y’, ‘determine segmentation id for a network’ etc.
I've been thinking about this, but would tend to reach the conclusion
that the things we need to interact with are pretty hard to abstract out
into something that would be generic across different agents.
Everything we need to do in our case relates to how the agents use
bridges and represent networks internally: linuxbridge has one bridge
per Network, while OVS has a limited number of bridges playing different
roles for all networks with internal segmentation.
To look at the two things you mention:
- "connect endpoint X to Y" : what we need to do is redirect the traffic
destinated to the gateway of a Neutron network, to the thing that will
do the MPLS forwarding for the right BGP VPN context (called VRF), in
our case br-mpls (that could be done with an OVS table too) ; that
action might be abstracted out to hide the details specific to OVS, but
I'm not sure on how to name the destination in a way that would be
agnostic to these details, and this is not really relevant to do until
we have a relevant context in which the linuxbridge would pass packets
to something doing MPLS forwarding (OVS is currently the only option we
support for MPLS forwarding, and it does not really make sense to mix
linuxbridge for Neutron L2/L3 and OVS for MPLS)
- "determine segmentation id for a network": this is something really
OVS-agent-specific, the linuxbridge agent uses multiple linux bridges,
and does not rely on internal segmentation
Completely abstracting out packet forwarding pipelines in OVS and
linuxbridge agents would possibly allow defining an interface that agent
extension could use without to know about anything specific to OVS or
the linuxbridge, but I believe this is a very significant taks to tackle.
Hopefully it will be acceptable to create an interface, even it exposes
a set of methods specific to the linuxbridge agent and a set of methods
specific to the OVS agent. That would mean that the agent extension
that can work in both contexts (not our case yet) would check the agent
type before using the first set or the second set.
Does this approach make sense ?
-Thomas
_________________________________________________________________________________________________________________________
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.
More information about the OpenStack-dev
mailing list