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?
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_controlle r_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/ docs.openstack. org/developer/ neutron/ devref/ callbacks. html
[2] http://