Open Stack

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:ihrachys at 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.morin at 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 <ihrachys at redhat.com> wrote:
>>
>>>> On 30 Sep 2015, at 12:53, Miguel Angel Ajo <mangelajo at redhat.com> wrote:
>>>>
>>>>
>>>>
>>>> Ihar Hrachyshka wrote:
>>>>>> On 30 Sep 2015, at 12:08, thomas.morin at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev