Open Stack

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/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