Hi Cathy, Could you please check on this. My mother passed away yesterday and I will be on leave for couple of weeks.
Thanks Vikram On 09-Nov-2015 6:15 pm, "Ihar Hrachyshka" <ihrac...@redhat.com> wrote: > 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/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