Mailing List Archive

Re: [openstack-dev] [nova][cinder] Disabling nova volume-update (aka swap volume; aka cinder live migration)
>
> The solution is conceptually simple. We add a new API microversion in
> Cinder that adds and optional parameter called "generic_keep_source"
> (defaults to False) to both migrate and retype operations.
>
> This means that if the driver optimized migration cannot do the
> migration and the generic migration code is the one doing the migration,
> then, instead of our final step being to swap the volume id's and
> deleting the source volume, what we would do is to swap the volume id's
> and move all the snapshots to reference the new volume. Then we would
> create a user message with the new ID of the volume.
>

How would you propose to "move all the snapshots to reference the new volume"?
Most storage does not allow a snapshot to be moved from one volume to another.
really the only way a migration of a snapshot can work across all storage types
would be to incrementally copy the data from a source to a destination up to
the point of the oldest snapshot, create a new snapshot on the new volume, then
proceed through until all snapshots have been rebuilt on the new volume.


_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [openstack-dev] [nova][cinder] Disabling nova volume-update (aka swap volume; aka cinder live migration) [ In reply to ]
On 8/21/2018 5:36 AM, Lee Yarwood wrote:
> I'm definitely in favor of hiding this from users eventually but
> wouldn't this require some form of deprecation cycle?
>
> Warnings within the API documentation would also be useful and even
> something we could backport to stable to highlight just how fragile this
> API is ahead of any policy change.

The swap volume API in nova defaults to admin-only policy rules by
default, so for any users that are using it directly, they are (1)
admins knowingly shooting themselves, or their users, in the foot or (2)
operators have opened up the policy to non-admins (or some other role of
user) to hit the API directly. I would ask why that is.

--

Thanks,

Matt

_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators