yahoo-eng-team team mailing list archive

[Armando Migliaccio <1486882@xxxxxxxxxxxxxxxxxx>]

I read the spec and the use case description, and unless I miss
something I don't think that extending the port resource with a
tunnelling information is a viable solution. Ultimately a tunnel IP is a
property of a compute host or a subset of them. Each backend can choose
how to expose it to allow the wiring, and for that we don't need to
spill implementation details all the way to the API.

Please feel free to elaborate your use case further; until then, this is
provisionally rejected.

** Changed in: neutron
       Status: Confirmed => Won't Fix

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1486882

Title:
  ml2 port cross backends extension

Status in neutron:
  Won't Fix

Bug description:
  In some scenes using neutron, there are more than one backends of ML2,
  maybe two backends, one is openvswitch and the other is an mechanism
  driver that manage a lot of TOR switch. The ports in the same network,
  they may be made up of different ML2 backends. For openvswitch
  backends, the tunneling ip of a port is the same as ovs-agent host's
  ip. But for another kind of backends, there is no l2-agent, the
  tunneling ip of a port can not get from host configuration. So I
  think, we need to extend a new ml2 port attribute to record this
  tunnel connection info about ports. Maybe we can named it
  "binding:tunnel_connection".

  Another benefit of using this extension:
  In currently implement, for openvswitch backends, we get the tunneling ip of a port in this way: port -> binding:host -> agent -> agent configurations -> tunneling_ip. But by using this extension, we could get a tunneling ip in a simple way: port -> binding:tunnel_connection -> tunneling_ip.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1486882/+subscriptions