So far it seems I am the only one voicing an opinion.
Having said that, the mechanism to invoke the port status change is left to the mech driver/plugin managing that port, ie. it is implementation specific. For instance, a plugin that uses an SDN controller may already use some sort of sync mechanism that could be piggybacked to reflect status changes on the port.
This means that only internal parts of a Neutron system can affect the port status and that's ok because only Neutron has authority over a Neutron port, no other external entity. An API consumer may disable a port via admin_state_up. Now if you think that admin_state_up behavior is not well defined for a port, rather than adding a new attribute, I'd invite you to fix the one we already have :)
So far it seems I am the only one voicing an opinion.
Having said that, the mechanism to invoke the port status change is left to the mech driver/plugin managing that port, ie. it is implementation specific. For instance, a plugin that uses an SDN controller may already use some sort of sync mechanism that could be piggybacked to reflect status changes on the port.
This means that only internal parts of a Neutron system can affect the port status and that's ok because only Neutron has authority over a Neutron port, no other external entity. An API consumer may disable a port via admin_state_up. Now if you think that admin_state_up behavior is not well defined for a port, rather than adding a new attribute, I'd invite you to fix the one we already have :)