Open Stack

+operators

On 8/24/2018 4:08 PM, Matt Riedemann wrote:
> 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