Comment 9 for bug 1259910

Hi Max,

Indeed it's a lighter approach. I liked it. Maybe we should go and try to make a proof of concept patch for it.

...

Similar to the approach you presented, I was thinking here and if we just used the target_power_state field was used as our flag? Similar to ur pre_reservation_key.

Instead of setting the target_power_state in an async way, we could make the API to do two RPC calls:

First, a sync call that would check if the target_power_state is already set and do some validations (validate the driver_info, if the requested state is valid, etc...). If everything is good it would then set the target_power_state with the client requested state.

Second, it would then do an async call to actually trigger the power on/off of the node.

E.g:

1 - CLI sends a request to change power on the node
2 - API will make a sync call that will set the target_power_state.
3 - API will make an async call to change the power state.

Double call flow example:
1 - Points 1 and 2 from previous flow happened.
2 - API will try to make the sync call for setting the target_power_state but since the target_power_state is already set (or being set, and for that the node would be locked) a NodeLocked exception would be raised.

*I will try to make a proof of concept patch for the approach using the target_power_state as a flag.