Purpose: detect incompatibilities between VolumeDriver versions
Test description
Cover area
VolumeDriver operation / maintainability
User story
VolumeDriver updates (temporarily) lead to different versions running next to each other in a vpool. This means that VolumeDriver updates need to be backward compatible (~ volumes can be migrated from instances running old versions to instances running new versions) and generally also forward compatible (~ volumes can be migrated from instances running new versions to instances running old versions).
Potential problem that might occur
Expected behaviour: volume migration back and forth between different versions should work, i.e. the volumes can still be written to / read from and they respond to mgmt requests. In case of a compatibility issue, a possible symptom is that the volume migration does not succeed, i.e. the volume is stopped successfully on the old owner but it's not restarted successfully on the new owner.
Setup
General idea:
run two VolumeDriver instances, one with an old version (stable release) and one with a new version (unstable):
backward compatibility:
create a new vpool with the old version, expand it with a new version
create a volume on the old instance
start I/O
move volume to the new instance
I/O should not report errors
forward compatibility:
create a new vpool with the new version, expand it with an old version
create a volume on the new instance
start I/O
move volume to the old instance
I/O should not report errors
Note: the proposed test is not exhaustive in that it cannot not expose all potential incompatibilities, but only a first line of defense. Long running tests on mixed version vpools should still also be implemented.
Purpose: detect incompatibilities between VolumeDriver versions
Test description
Cover area
User story
VolumeDriver updates (temporarily) lead to different versions running next to each other in a vpool. This means that VolumeDriver updates need to be backward compatible (~ volumes can be migrated from instances running old versions to instances running new versions) and generally also forward compatible (~ volumes can be migrated from instances running new versions to instances running old versions).
Potential problem that might occur
Expected behaviour: volume migration back and forth between different versions should work, i.e. the volumes can still be written to / read from and they respond to mgmt requests. In case of a compatibility issue, a possible symptom is that the volume migration does not succeed, i.e. the volume is stopped successfully on the old owner but it's not restarted successfully on the new owner.
Setup
General idea:
Note: the proposed test is not exhaustive in that it cannot not expose all potential incompatibilities, but only a first line of defense. Long running tests on mixed version vpools should still also be implemented.