Hi Ihar, Thanks for initiating this discussion. I am in OPNFV Summit. Henry Fourie of SFC project team will reply with our feedback.
Cathy -----Original Message----- From: Ihar Hrachyshka [mailto:ihrac...@redhat.com] Sent: Monday, November 09, 2015 4:44 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron][sfc] How could an L2 agent extension access agent methods ? Thanks Thomas, much appreciated. I need to admit that we haven’t heard from SFC folks just yet. I will try to raise awareness that we wait for their feedback today on team meeting. Adding [sfc] tag to the topic to get more attention. Ihar Thomas Morin <thomas.mo...@orange.com> wrote: > Hi Ihar, > > Ihar Hrachyshka : >> Reviving the thread. >> [...] (I appreciate if someone checks me on the following though): > > This is an excellent recap. > >> I set up a new etherpad to collect feedback from subprojects [2]. > > I've filled in details for networking-bgpvpn. > Please tell me if you need more information. > >> Once we collect use cases there and agree on agent API for extensions >> (even if per agent type), we will implement it and define as stable >> API, then pass objects that implement the API into extensions thru >> extension manager. If extensions support multiple agent types, they >> can still distinguish between which API to use based on agent type >> string passed into extension manager. >> >> I really hope we start to collect use cases early so that we have >> time to polish agent API and make it part of l2 extensions earlier in >> Mitaka cycle. > > We'll be happy to validate the applicability of this approach as soon > as something is ready. > > Thanks for taking up this work! > > -Thomas > > > >> Ihar Hrachyshka <ihrac...@redhat.com> wrote: >> >>>> On 30 Sep 2015, at 12:53, Miguel Angel Ajo <mangel...@redhat.com> wrote: >>>> >>>> >>>> >>>> Ihar Hrachyshka wrote: >>>>>> On 30 Sep 2015, at 12:08, thomas.mo...@orange.com wrote: >>>>>> >>>>>> 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. >>>>> >>>>> If you look for a clean way to integrate with reference agents, >>>>> then it’s something that we should try to achieve. I agree it’s >>>>> not an easy thing. >>>>> >>>>> Just an idea: can we have a resource for traffic forwarding, >>>>> similar to security groups? I know folks are not ok with extending >>>>> security groups API due to compatibility reasons, so maybe fwaas >>>>> is the place to experiment with it. >>>>> >>>>>> 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. >>>>> >>>>> The assumption of the whole idea of l2 agent extensions is that >>>>> they are agent agnostic. In case of QoS, we implemented a common >>>>> QoS extension that can be plugged in any agent [1], and a set of >>>>> backend drivers (atm it’s just sr-iov [2] and ovs [3]) that are >>>>> selected based on the driver type argument passed into the >>>>> extension manager [4][5]. Your extension could use similar >>>>> approach to select the backend. >>>>> >>>>> [1]: >>>>> https://git.openstack.org/cgit/openstack/neutron/tree/neutron/agen >>>>> t/l2/extensions/qos.py#n169 >>>>> [2]: >>>>> https://git.openstack.org/cgit/openstack/neutron/tree/neutron/plug >>>>> ins/ml2/drivers/mech_sriov/agent/extension_drivers/qos_driver.py >>>>> [3]: >>>>> https://git.openstack.org/cgit/openstack/neutron/tree/neutron/plug >>>>> ins/ml2/drivers/openvswitch/agent/extension_drivers/qos_driver.py >>>>> [4]: >>>>> https://git.openstack.org/cgit/openstack/neutron/tree/neutron/plug >>>>> ins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py#n395 >>>>> [5]: >>>>> https://git.openstack.org/cgit/openstack/neutron/tree/neutron/plug >>>>> ins/ml2/drivers/mech_sriov/agent/sriov_nic_agent.py#n155 >>>> >>>> I disagree on the agent-agnostic thing. QoS extension for SR-IOV is >>>> totally not agnostic for OVS or LB, in the QoS case, it's just >>>> accidental that OVS & LB share common bridges now due to the OVS >>>> Hybrid implementation that leverages linux bridge and iptables. >>> >>> Wait. The QoS extension has nothing agent backend specific. All it >>> does is it receives rpc updates for tracked resources and pass them >>> into qos drivers. Those latter are the bits that implement backend >>> specific operations. So I am not sure why you say the extension >>> itself is agent >>> specific: any other amqp based agent in the wild can adopt the >>> extension as-is, only providing a new backend to load. >>> >>>> I agree on having a well defined interface, on which API is >>>> available to talking back to each agent, and it has to be common, >>>> where it's possible to be common. >>>> >>>> It doesn't have to be easy, but it's the way if we want a world >>>> where those commonalities and reusability of extensions can exist >>>> and not be just accidental, but it's not realistic in my opinion to >>>> AIM for it on every shot. I believe we should try where we can but >>>> we should be open to agent specific extensions. The idea of the >>>> extensions is that you can extend specific agents without being >>>> forced to have the main loop hijacked, or eventually having off >>>> tree code plugged into our agents. >>> >>> Partially, yes. The culprit here is how much the extension API >>> should know about an agent. We can probably make the extension API >>> completely extendable by allowing agents to pass any random kwargs >>> into the extension manager that will forward them into extensions. >>> Note that it breaks current API for extensions and technically >>> breaks it (not that I know of any external extensions that could be >>> affected so far). >>> >>>> There we should add support to identify the type of agent the >>>> extension works with (compatibility, versioning, etc..) >>> >>> We already pass the type into extension manager, and that’s how we >>> plug in the proper backend driver in QoS. >>> >>>>>> 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. >>>>> >>>>> Note that you should really avoid putting that ^^ kind of >>>>> signature into your emails intended for public mailing lists. If >>>>> it’s confidential, why do you send it to everyone? And sorry, >>>>> folks will copy it without authorisation, for archiving and >>>>> indexing reasons and whatnot. >>>>> >>>>> Ihar > > > ______________________________________________________________________ > ____ 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 __________________________________________________________________________ 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