Comment 3 for bug 1598081

Yes, [1] is in line with this RFE. I may be missing how exactly a mech driver would be triggered to invoke set_status() as no hints are given in there or in bug #1587401. I have some thoughts on that and very briefly mentioned two of many possible approaches in this RFE description. A bit more --verbose:

1) allow read-write of Port 'status' through the REST API (currently read-only)
   + easy to implement
   + SDN controllers and 3rd parties could call as REST API clients
   - conceptually call should flow bottom-up

2) introduce 'force-down' parameter in Port -- similar to what was done in Nova (force mark host down)
   + easy to implement
   + SDN controllers and 3rd parties could call as REST API clients
   - could potentially conflict with admin_status_up (actually its role is not that much well defined/formalized but...)
   - conceptually call should flow bottom-up

3) extend each mech driver in such a way it could receive callbacks (via e.g. REST, RPC, etc) from SDN controllers; perhaps that's the idea [1] have in mind?
   + each mech driver plugin could have its own and different implementation
   - lacking of common approach cross-mech drivers or duplicated code if many implement same way
   - N listeners per N mech driver, plus authentication and authorization would be needed be validate caller.
   - tightly coupled with and supporting updating only from mech drivers

4) new neutron plugin receiving callbacks from SDN controllers, generating notification message and dispatching via Neutron callback system [2]. An internal Neutron component (e.g. mech driver) subscribed to that event (e.g. type=='port_status_update' and source=='sdn_controller_X') would be called back
   + plugin could be extended to support REST, RPC, etc calls
   + 3rd parties could also invoke it
   + works bottom-up and up-bottom-up; I'm calling this "roller coaster" flow approach :-)
   + not tightly coupled to a neutron component (e.g. mech driver)
   +/- multiple neutron components could be called back simultaneously; possibly beneficial for cases like neutron servers (FWaaS, LBaaS) that could use such information to update services status quickly/in parallel with neutron port status (just "thinking out loud"...)
   - confusing?

[1] https://review.openstack.org/#/c/336068/
[2] http://docs.openstack.org/developer/neutron/devref/callbacks.html