Open Stack

I just pushed an update to the neutron spec [1], describing the general 
purpose portbinding API that we decided on in Tuesdays Nova-Neutron 
Cross project session.

Please review it and let me know, if I understood everything correctly!

When going down the path with the general purpose API, some new 
questions do arise. The main question is, if this new API should only 
cover compute bindings or also all other kind of bindngs (DVR)?
As soon as the scope is clear, I can start figuring out what that means 
for ML2 and the database (OVO) models.
All questions are all listed further below, but they are also in the 
spec under the corresponding API. Please reply on the spec if you have 
any opinion on that.

Thanks!

Andreas

[1] https://review.openstack.org/#/c/309416/

Questions on List Bindings:
* Should only compute bindings get listed? Or all kind of bindings,
   including DVR bindings?
* Should all the details be listed, or just a subset?
* That list might get pretty long for DVR ports. How  and when to limit the
   output?


Questions on Show Binding:
* If DVR is also externalized
   * probably some additional fields are of interest (router_id, something
    else?)
   * Today a dvr port is shown with vif_type = 'distributed', although 
it has
     a real vif_type like 'ovs'. How to deal with that in this API?
     Should there be an extra flag showing, whether a port is distributed or
     not?

Questions on Create Binding:
* Should there be a limit for creating bindings?
* Do we need a mechanism to ensure that only 1 binidng can be active for
   a compute port? I think so!
* Should the creation of a binding be restricted to ports with compute
   bindings? What about creating bindings for a router, dhcp port?
* Should we have a capability to create a binding based on an existing 
binding
   (for live migration)? Or should nova take care of creating the second
   binding with exactly the same data?
* Shall this API replace the existing API in the future (today a binding
   for a port gets created by setting the binding:host parameter).
* Should status be a attribute of create? Or would we always create inactive
   port and then force the user to activate it via the activate API? Or 
should
   the first binding become activated by default, while all others need
   explicit activation?
* Would we consider a failed binding as an client issue (4xx code) or a 
server
   issue (5xx code)? Ideas for concrete http codes?
* Can we make the MAC address part of a binding (sr-iov migration?)

Questions on update binding:
* Should the status field be modifiable?

Questions on activate binding:
* Is this required at all? We could also activate a binding when updating
   the status field of a binding.
* Should this automatically deactivate all active bindings? Or is deactivate
   an explicit step?