+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
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
