Open Stack

On 8/23/2018 10:22 AM, Sean McGinnis wrote:
> I haven't gone through the workflow, but I thought shelve/unshelve could detach
> the volume on shelving and reattach it on unshelve. In that workflow, assuming
> the networking is in place to provide the connectivity, the nova compute host
> would be connecting to the volume just like any other attach and should work
> fine. The unknown or tricky part is making sure that there is the network
> connectivity or routing in place for the compute host to be able to log in to
> the storage target.

Yeah that's also why I like shelve/unshelve as a start since it's doing 
volume detach from the source host in the source cell and volume attach 
to the target host in the target cell.

Host aggregates in Nova, as a grouping concept, are not restricted to 
cells at all, so you could have hosts in the same aggregate which span 
cells, so I'd think that's what operators would be doing if they have 
network/storage spanning multiple cells. Having said that, host 
aggregates are not exposed to non-admin end users, so again, if we rely 
on a normal user to do this move operation via resize, the only way we 
can restrict the instance to another host in the same aggregate is via 
availability zones, which is the user-facing aggregate construct in 
nova. I know Sam would care about this because NeCTAR sets 
[cinder]/cross_az_attach=False in nova.conf so servers/volumes are 
restricted to the same AZ, but that's not the default, and specifying an 
AZ when you create a server is not required (although there is a config 
option in nova which allows operators to define a default AZ for the 
instance if the user didn't specify one).

Anyway, my point is, there are a lot of "ifs" if it's not an 
operator/admin explicitly telling nova where to send the server if it's 
moving across cells.

> 
> If it's the other scenario mentioned where the volume needs to be migrated from
> one storage backend to another storage backend, then that may require a little
> more work. The volume would need to be retype'd or migrated (storage migration)
> from the original backend to the new backend.

Yeah, the thing with retype/volume migration that isn't great is it 
triggers the swap_volume callback to the source host in nova, so if nova 
was orchestrating the volume retype/move, we'd need to wait for the swap 
volume to be done (not impossible) before proceeding, and only the 
libvirt driver implements the swap volume API. I've always wondered, 
what the hell do non-libvirt deployments do with respect to the volume 
retype/migration APIs in Cinder? Just disable them via policy?

-- 

Thanks,

Matt