On 25/08, Sean McGinnis wrote: > On Fri, Aug 24, 2018 at 04:20:21PM -0500, Matt Riedemann wrote: > > On 8/20/2018 10:29 AM, Matthew Booth wrote: > > > Secondly, is there any reason why we shouldn't just document then you > > > have to delete snapshots before doing a volume migration? Hopefully > > > some cinder folks or operators can chime in to let me know how to back > > > them up or somehow make them independent before doing this, at which > > > point the volume itself should be migratable? > > > > Coincidentally the volume migration API never had API reference > > documentation. I have that here now [1]. It clearly states the preconditions > > to migrate a volume based on code in the volume API. However, volume > > migration is admin-only by default and retype (essentially like resize) is > > admin-or-owner so non-admins can do it and specify to migrate. In general I > > think it's best to have preconditions for *any* API documented, so anything > > needed to perform a retype should be documented in the API, like that the > > volume can't have snapshots. > > That's where things get tricky though. There aren't really reconditions we can > have as a blanket statement with the retype API. > > A retype can do a lot of different things, all dependent on what type you are > coming from and trying to go to. There are some retypes where all it does is > enable vendor flag ``foo`` on the volume with no change in any other state. > Then there are other retypes (using --migrate-policy on-demand) that > completely > move the volume from one backend to another one, copying every block along the > way from the original to the new volume. It really depends on what types you > are trying to retype to. >
We can say that retypes that require migration between different vendor backends cannot be performed with snapshots, and between arrays from the same vendor will depend on the driver (though I don't know if any driver can actually pull this off). Cheers, Gorka. > > > > [1] https://review.openstack.org/#/c/595379/ > > > > -- > > > > Thanks, > > > > Matt > > > > __________________________________________________________________________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev