<div dir="ltr">Hi,
<div><br></div><div>This all started when we were testing Evacuate with our storage driver.</div><div>We thought we found a bug (<a href="https://bugs.launchpad.net/cinder/+bug/1491276">https://bugs.launchpad.net/cinder/+bug/1491276</a>) then Scott replied that we should be running cinder-volume service separate from nova-compute.</div><div>For some internal reasons we can't do that - yet, but we have some questions regarding the behavior of the service:</div><div><br></div><div>- on our original test setup we have 3 nodes (1 controller + compute + cinder, 2 compute + cinder).</div><div>-- when we shutdown the second node and tried to evacuate, the call was routed to cinder-volume of the halted node instead of going to other nodes (there were still 2 cinder-volume services up) - WHY?</div><div>- on the new planned setup we will have 6 nodes (3 dedicated controller + cinder-volume, 3 compute)</div><div>-- in this case which cinder-volume will manage which volume on which compute node?</div><div>-- what if: one compute node and one controller go down - will the Evacuate still work if one of the cinder-volume services is down? How can we tell - for sure - that this setup will work in case ANY 1 controller and 1 compute nodes go down? </div><div><br></div><div>Hypothetical: </div><div>- if 3 dedicated controller + cinder-volume nodes work can perform evacuate when one of them is down (at the same time with one compute), WHY can't the same 3 nodes perform evacuate when compute services is running on the same nodes (so 1 cinder is down and 1 compute)</div><div>- if the answer to above question is "They can't " then what is the purpose of running 3 cinder-volume services if they can't handle one failure?</div><div>- and if the answer to above question is "You only run one cinder-volume" then how can it handle failure of controller node?</div><div><br></div><div>Thanks,</div><div><br></div><div>Eduard</div></div>