Group actions enable, disable and failover replication can leave volume's replication status in transient states enabling, disabling and failing-over respectively.

[prashkre]

Consider a group(grp_1) has 3 volumes(vol_1, vol_2, vol_3) and initially all the volume's replication_status is 'disabled'. When a user executes below use-cases concurrently, their is a probability that volume's replication_status gets stuck in 'enabling' status.

 -- attach all volumes(vol_1, vol_2, vol_3) to some Virtual Machine.
 -- any of group enable_replication, disable_replication and failover_replication operations

Here is an example scenario that leaves replication_status of vol1 in 'enabling' status.

1. vol_1 attach operation started and completed it has put the volume in 'in-use' status.
2. vol_2 attach operation started, it has put the volume in 'attaching' status and it is still in progress.
3. group enable_replication is triggered, which puts vol_1 replication_status in 'enabling' status, vol2 status check fails at [0] and leaves vol_1 replication_status in 'enabling' status.

[0]
https://github.com/openstack/cinder/blob/master/cinder/group/api.py#L1008

Same scenario can be applicable with disable and failover replication on group with any operations on volumes in the groups.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.opendev.org/c/openstack/cinder/+/871649