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
