cloudstack-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From GitBox <...@apache.org>
Subject [GitHub] mike-tutkowski commented on issue #2298: CLOUDSTACK-9620: Enhancements for managed storage
Date Thu, 01 Jan 1970 00:00:00 GMT
mike-tutkowski commented on issue #2298: CLOUDSTACK-9620: Enhancements for managed storage
URL: https://github.com/apache/cloudstack/pull/2298#issuecomment-356740607
 
 
   @rafaelweingartner Sure, I'm happy to help.
   
   A couple things:
   
   1) If you are just looking for a host to perform the operation (in my use case, it's a
copy of a volume snapshot that's on secondary storage to a new template, which is also, as
always, on secondary storage), then you don't need that join on the cluster_details table
in HostDaoImpl.createSqlFindHostConnectedToStoragePoolToExecuteCommand. We only need to check
that field in cluster_details when we'd like to perform a UUID resignature of an SR and/or
a VDI on XenServer, which we don't here.
   
   2) I'm curious why we don't just do the following: Look up the hypervisor type of the volume
snapshot in cloud.snapshots. Find any host of that hypervisor type in the applicable zone
and use it to perform the operation. This would solve the problem of having to find a storage
pool that may no longer be in use. In any event, once the volume snapshot is on secondary
storage, we don't really care what storage pool it came from, right? I think we just care
what hypervisor type it came from.

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services

Mime
View raw message