Open Stack

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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev