I have rethought how to resolve this problem after submitting patch-set 9.
But, I couldn't bethink better ideas.
I think that the current idea is the only feasible one.
The other ideas below have big problems.
--------------
(1)Delete garbage BDM records when new BDM record is created.
pros:
* This idea is very simple.
* This idea guards BDM table from corruption.
cons:
* There will be several corrected BDM records if we specify a multi-attached volume.[1] In this case, distinguishing gaarbage records from in-progress records is impossible.
--------------
(2)Cinder decide to process or not.
Cinder decide to process or not by self when it receives terminate_connection API/detach API.
I think that we can use volume_attachment records for above decision.
But, volume_attachment record is currently created at detach API process. This is too late.
volume_attachment record should be created at first of initialize_connection API process for above decision.
And, we should add "instance_uuid" parameter to initialize_connection API.
Otherwise we couldn't find out the volume_attachment record created at initialize_connection API in detach API process.
pros:
* Cinder already decide to change status or not in detach process. So adding conditional branches to cinder is looks natural to me.
cons:
* Changing initialize-connection API interface doesn't support backward compatibility.
(Reprint from gerrit)
I have rethought how to resolve this problem after submitting patch-set 9.
But, I couldn't bethink better ideas.
I think that the current idea is the only feasible one.
The other ideas below have big problems.
--------------
(1)Delete garbage BDM records when new BDM record is created.
pros:
* This idea is very simple.
* This idea guards BDM table from corruption.
cons:
* There will be several corrected BDM records if we specify a multi-attached volume.[1] In this case, distinguishing gaarbage records from in-progress records is impossible.
[1]"multi- attach- volume" bp (https:/ /blueprints. launchpad. net/nova/ +spec/multi- attach- volume) is in-progress.
-------------- connection API/detach API.
(2)Cinder decide to process or not.
Cinder decide to process or not by self when it receives terminate_
I think that we can use volume_attachment records for above decision. connection API process for above decision.
But, volume_attachment record is currently created at detach API process. This is too late.
volume_attachment record should be created at first of initialize_
And, we should add "instance_uuid" parameter to initialize_ connection API. connection API in detach API process.
Otherwise we couldn't find out the volume_attachment record created at initialize_
pros:
* Cinder already decide to change status or not in detach process. So adding conditional branches to cinder is looks natural to me.
cons: connection API interface doesn't support backward compatibility.
* Changing initialize-
--------------