Open Stack

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" <ihrachys at 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.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/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-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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151110/38a1010f/attachment.html>