commit 706cbf40f5f8c6f756277057c92bf41f1ef1cd80
Author: John Griffith <email address hidden>
Date: Tue May 12 08:03:27 2015 -0600
Check type match on create from source/snap
We used to allow creating from source/snap and specifying a
different type than the originating resource when doing so.
Once we started getting more drivers and more multi-backend
configurations, we implemented a check in volume.api that
took this away (broke it). There have been a number of
arguments about whether this should be allowed or not, and
that it could fail after the rpc call leaving the user with
nothing more than a "failed" volume and no explanation as to
why.
This patch allows the capability, but checks validity at the
API layer before issuing the create call. There are two
requirements for the new type specification to be valid:
1. There is only one backend (cinder-volume) topic configured
2. Both types in question specify the same volume_backend_name
If neither of these requirements are met, the user will receive
an "invalid type" error explaining that the type combination is
not compatible and that they should omit the type argument altogether.
Reviewed: https:/ /review. openstack. org/182327 /git.openstack. org/cgit/ openstack/ cinder/ commit/ ?id=706cbf40f5f 8c6f756277057c9 2bf41f1ef1cd80
Committed: https:/
Submitter: Jenkins
Branch: master
commit 706cbf40f5f8c6f 756277057c92bf4 1f1ef1cd80
Author: John Griffith <email address hidden>
Date: Tue May 12 08:03:27 2015 -0600
Check type match on create from source/snap
We used to allow creating from source/snap and specifying a
different type than the originating resource when doing so.
Once we started getting more drivers and more multi-backend
configurations, we implemented a check in volume.api that
took this away (broke it). There have been a number of
arguments about whether this should be allowed or not, and
that it could fail after the rpc call leaving the user with
nothing more than a "failed" volume and no explanation as to
why.
This patch allows the capability, but checks validity at the
API layer before issuing the create call. There are two
requirements for the new type specification to be valid:
1. There is only one backend (cinder-volume) topic configured
2. Both types in question specify the same volume_backend_name
If neither of these requirements are met, the user will receive
an "invalid type" error explaining that the type combination is
not compatible and that they should omit the type argument altogether.
Change-Id: I08bc5e9a8800ce 3b27c7db90b7bff 86d7d14359a
Closes-Bug: #1289931