Repository navigation
Enhancing storagepool operations and snapshot related fixes in NetApp ONTAP storage plugin #13897
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
761abf4
f52ec62
30c03fc
82cbf1f
63f788f
04ef174
42c031d
7007fa4
c22db54
695dac6
c77301f
45a9b5d
34630fa
f1a1d29
f3dd17b
ca43eed
1bc57d4
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -448,7 +448,7 @@ public synchronized boolean deleteStoragePool(StoragePoolType type, String uuid) | |
| if (type == StoragePoolType.NetworkFilesystem) { | ||
| _haMonitor.removeStoragePool(uuid); | ||
| } | ||
| boolean deleteStatus = adaptor.deleteStoragePool(uuid);; | ||
| boolean deleteStatus = adaptor.deleteStoragePool(uuid); | ||
| synchronized (_storagePools) { | ||
| _storagePools.remove(uuid); | ||
| } | ||
|
|
@@ -457,10 +457,12 @@ public synchronized boolean deleteStoragePool(StoragePoolType type, String uuid) | |
|
|
||
| public boolean deleteStoragePool(StoragePoolType type, String uuid, Map<String, String> details) { | ||
| StorageAdaptor adaptor = getStorageAdaptor(type); | ||
| // For NetworkFilesystem, libvirt will take care of unmounting the nfs mount. If nfs mount has been removed before libvirt's pool | ||
| // delete, libvirt will throw an error. | ||
| boolean deleteStatus = adaptor.deleteStoragePool(uuid, details); | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Why was this moved to before the removal from the HA monitor? Can't it result in a situation where the HA monitor has a reference to a storage, but the pool was already unmounted?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. For NFS, libvirt owns the mount, so If This way libvirt could handle the unmount and mount properly. And while deleting the entry from the HA map in haMonitor, the `umount' could be a backup. (This fixes #12690)
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @sandeeplocharla I think this specific change (the unmount cancel fix) needs more discussion and testing, as it impacts other storage pool types as well. It fixes the NFS case, but seems to break SharedMountPoint storages. With this change, SMPs will be unmounted by the HA monitor on the next heartbeat after being put into maintenance, resulting in a "Up but unmounted" storage after the maintenance is canceled, since CloudStack doesn't remount them automatically. Could you remove the changes of #14187 from this PR? Then it's good to merge from my side, and we can discuss this fix in #14187.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hi @winterhazel, I see that NetworkFilesystem, SharedMountPoint, Gluster, Filesystem, and RBD all use LibvirtStorageAdaptor. Before this override, that call used the StorageAdaptor default, which returns true and does not destroy the libvirt pool. The override forwards all five types to deleteStoragePool(uuid), so entering maintenance now destroys the SharedMountPoint libvirt pool too. The pool stays in the HA monitor, and the next heartbeat unmounts it. The default is not enough for NetworkFilesystem, because libvirt has to handle the pool. The real delete can stay limited to NetworkFilesystem, with the other types left on the old no-op:
OR
What do you think? |
||
| if (type == StoragePoolType.NetworkFilesystem) { | ||
| _haMonitor.removeStoragePool(uuid); | ||
| } | ||
| boolean deleteStatus = adaptor.deleteStoragePool(uuid, details); | ||
| synchronized (_storagePools) { | ||
| _storagePools.remove(uuid); | ||
| } | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can this be null (any case where no volume associated with the given uuid)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
getComponent()already rejects a missing or malformed path (length != 3→ CloudRuntimeException).