Cannot resize a volume with different tags, therefore cannot migrate it to different storage pools #3561
Description
ISSUE TYPE
- Bug Report
- Improvement Request
COMPONENT NAME
API, Storage tags
CLOUDSTACK VERSION
master
CONFIGURATION
OS / ENVIRONMENT
SUMMARY
If you'd like to upgrade a volume, let's say from a normal hard drive to SSD and all the storage pools and offerings are tagged with different tags, there's no other way to do that except from updating the offering ID in the DB and migrating it to the desired storage pool.
Cloudstack currently simply requires tags to match when executing the resize volume API, We need to be able to make more intelligent checks and offer the user a way to 'upgrade/downgrade' a volume based on the tags he's using.
STEPS TO REPRODUCE
EXPECTED RESULTS
User must be able to resize to a different type of offering according to tags
ACTUAL RESULTS
He's not
Activity
onitake commented on Aug 19, 2019
According to feedback from @DaanHoogland , the changes required to implement this would be significant. There are quite a few cases to cover when storage tags change.
But for the time being, it would be great if at least the UI behaviour could be fixed. Since it's already possible to change the storage offering via the API/CLI when storage tags are unchanged, the UI should also reflect this. Currently, it's not possible at all to change the offering, because the disk size field on a custom offering is mandatory, and when it contains a value, no migration is performed at all.
DaanHoogland commented on Oct 28, 2020
@borisstoyanov @onitake is this issue still needed?
GabrielBrascher commented on Oct 28, 2020
Maybe this issue has something to do with #4257?
DaanHoogland commented on Nov 24, 2020
I am sure this has to do with #4257, but that is a quite rude way to solve it, maybe more discussion is needed (here or on the maillist)
I think doing it well, is a lot of work, while doing the #4257 way leave too many holes open. (not 👎-ing that PR here)
yadvr commented on Aug 9, 2021
cc @harikrishna-patnala @sureshanaparti - could it work now with the PR being referenced and your work?
nvazquez commented on Aug 24, 2021
As discussed offline, this will be handled by PR #5008, will need verification
harikrishna-patnala commented on Aug 25, 2021
Yes @nvazquez @rhtyd, there are options to either update the disk offering or migrate the volume to a different storage pool using APIs. so this can be verified as part PR#5008
yadvr commented on Sep 21, 2021
@harikrishna-patnala cc @nvazquez can you check if I've correctly moved this to 4.17 milestone; or is somebody working on this?
nvazquez commented on Sep 21, 2021
Its fine @rhtyd as PR #5008 has been moved to the 4.17 milestone and will address this issue
onitake commented on Jan 27, 2022
Thanks for fixing! 👏