Issuing v2 replication commands against a non-replicated volume type puts replication_status into an unrecoverable state

[Alex O'Rourke]

The v2 replication commands can currently be issued against non replicated type volumes. When this is done, replication_status gets stuck in an unrecoverable state.

For example, with enable_replication, the volume API puts the volume's replication_status in 'enabling' state, then calls the driver. If the driver detects the volume is not of replicated type, it can raise an exception and not actually do anything. At this point, replication_status is stuck in 'enabling' state. There needs to be a check that allows the driver to say the volume is not replicated so replication_status can be adjusted.

This can also happen if the volume is of replicated type and another error is thrown. In the above scenario, replication_status will be stuck at 'enabling'. Once the error is resolved, no replication commands can be run against said volume.

[John Griffith (john-griffith)]

Unfortunately the initial V1 implementation here:
https://github.com/openstack/cinder/commit/1c8f49bfe9fe3abd713e28922d5551f71228624c

Sets the default volume object to replication_status=disabled on volume create in the taskflow API. This is kind of confusing, there's no way to know is it disabled because "we disabled it" or is it just flat out not supported?

I think the fix here is to initialize this to None or perhaps "unsupported-type" or something like that.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/231753

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/231753
Committed: https://git.openstack.org/cgit/openstack/cinder/commit/?id=1ca450fe232eef79fa0040f467fd79e8b2504ca5
Submitter: Jenkins
Branch: master

commit 1ca450fe232eef79fa0040f467fd79e8b2504ca5
Author: John Griffith <email address hidden>
Date: Tue Oct 6 17:15:58 2015 -0600

    Verify volume is replication capable

    The V1 implementation of replication added a replication_status
    field to the Volume object and set it to disabled by default on
    volume creation.

    This is problematic, because there's no way for the API or any
    caller to know if the status is disabled because it was
    explicitly set that way, or if it is because the back end or
    volume-type do not support replication.

    This results in cases like enable replication (which does a status
    check on disabled) to be called inappropriately on devices that
    don't support replication.

    This patch adds a decorator to the new replication methods which will
    check that the volume is of type with replication_enabled=True before
    attempting any replication related operations.

    Change-Id: I943be2aef3b7c32026278f311dae9f82194372fe
    Closes-Bug: #1503439

[Thierry Carrez (ttx)]

This issue was fixed in the openstack/cinder 8.0.0.0b1 development milestone.