Dmitriy, are you sure you waited for completion of all deployment tasks on the compute node? (the ones that configure OVS and Ceph seem to be executed relatively late)
We could use an ugly hack to work around the corner case with an OVS bridge, but, as I mentioned in the comments, there are more similar problems, e.g. the one with Ceph (https://bugs.launchpad.net/fuel/+bug/1536115). I.e. the external orchestration that triggers the redeployment process must disable / enable nova-compute and its workloads (or migrate those).
Dmitriy, are you sure you waited for completion of all deployment tasks on the compute node? (the ones that configure OVS and Ceph seem to be executed relatively late)
I gave it another try on 9.0 and still believe the approach described in https:/ /bugs.launchpad .net/fuel/ +bug/1477475/ comments/ 13 and https:/ /bugs.launchpad .net/fuel/ +bug/1477475/ comments/ 14 is the preferred way, thus, fixing the docs and the way we tackle this to make sure workloads are properly disabled/migrated before doing redeployment of a compute node.
We could use an ugly hack to work around the corner case with an OVS bridge, but, as I mentioned in the comments, there are more similar problems, e.g. the one with Ceph (https:/ /bugs.launchpad .net/fuel/ +bug/1536115). I.e. the external orchestration that triggers the redeployment process must disable / enable nova-compute and its workloads (or migrate those).
Docs team, I suggest we update the docs as it's described here - https:/ /bugs.launchpad .net/fuel/ +bug/1477475/ comments/ 14