Thanks ihar! On Thu, Nov 19, 2015 at 2:32 PM, Ihar Hrachyshka <ihrac...@redhat.com> wrote:
> UPD: now that we have some understanding what’s needed from l2 agent > extension mechanism to cater for interested subprojects (and now that we > see that probably the agent in focus right now is OVS only), we may move to > RFE step. I reported the following RFE for the feature: > > https://bugs.launchpad.net/neutron/+bug/1517903 > > It may require BP if drivers team will request one. > > Cheers, > > Ihar > > Ihar Hrachyshka <ihrac...@redhat.com> wrote: > > Reviving the thread. >> >> On the design summit session dedicated to agent and plugin extensions [1] >> the following was stated for l2 agent extensions (I appreciate if someone >> checks me on the following though): >> >> - current l2 agent extensions mechanism lacks insight into agent details >> like bridges or vlan maps; >> >> - in some cases, we don’t care about extension portability across >> multiple agents, so it’s not of concern if some of them use implementation >> details like bridges to set specific flows, or to wire up some additional >> ports to them; >> >> - that said, we still don’t want extensions to have unlimited access to >> agent details; the rationale for hard constraints on what is seen inside >> extensions is that we cannot support backwards compatibility for *all* >> possible internal attributes of an agent; instead, we should explicitly >> define where we can make an effort to provide stable API into agent >> details, and what’s, on contrary, beyond real life use cases and hence can >> be left to be broken/refactored as neutron developers see fit; this API can >> be agent specific though; >> >> - agent details that are to be passed into extensions should be driven by >> actual use cases. There were several subprojects mentioned in the session >> that are assumed to lack enough access to agent attributes to do their job >> without patching core ovs agent files. Those are: BGP-VPN, SFC, (anything >> else?) Those subprojects that are interested in extending l2 agent >> extension framework are expected to come up with a list of things missing >> in current implementation, so that neutron developers can agree on proper >> abstractions to provide missing details to extensions. For that goal, I set >> up a new etherpad to collect feedback from subprojects [2]. >> >> 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. >> >> [1]: https://etherpad.openstack.org/p/mitaka-neutron-core-extensibility >> [2]: https://etherpad.openstack.org/p/l2-agent-extensions-api-expansion >> >> Ihar >> >> 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/agent/l2/extensions/qos.py#n169 >>>>> [2]: >>>>> https://git.openstack.org/cgit/openstack/neutron/tree/neutron/plugins/ml2/drivers/mech_sriov/agent/extension_drivers/qos_driver.py >>>>> [3]: >>>>> https://git.openstack.org/cgit/openstack/neutron/tree/neutron/plugins/ml2/drivers/openvswitch/agent/extension_drivers/qos_driver.py >>>>> [4]: >>>>> https://git.openstack.org/cgit/openstack/neutron/tree/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py#n395 >>>>> [5]: >>>>> https://git.openstack.org/cgit/openstack/neutron/tree/neutron/plugins/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 >>> >> >> __________________________________________________________________________ >> 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