Comment 1 for bug 1259910

So far I see two ways to fix it:
1. We could have a separate request to acquire lock. In this way we will be able to prevent race and the client will know whether it's request really will be started on the conductor. But I don't like distributed locking, e.g. one call for lock, then pause, AMQP lags?, second call to perform some job and release lock..
2. The second way is more reasonable to me - to make change_node_power_state synchronised, but since it's long, to do main conductor job in a separate thread. In other words, we will acquire lock, start a thread for the job and return the indication to the client that the lock was acquired and the job has started, or exception. But in such way we would steel need to invent a way to safely release lock in the end of the job, because it will already be outside of "with" block (we won't be able use context manager at all)