You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
storage_pool_details overprovisioning settings are being picked up as a tag #2758
update configuration name = "storage.overprovisioning.factor" value = 2.0 storageid = [pool.id]
Cloudstack api creates a record in the storage_pool_details table looking like that:
MariaDB [cloud]> select * from storage_pool_details;
+----+---------+---------------------------------+-------+---------+
| id | pool_id | name | value | display |
+----+---------+---------------------------------+-------+---------+
| 2 | 2 | storage.overprovisioning.factor | 2.0 | 1 |
+----+---------+---------------------------------+-------+---------+
1 row in set (0.00 sec)
At this point if you try to migrate a volume and change it's disk offering, it fails with
{errorcode : 431, errortext : u'Target Storage [id=26055c44-abb2-3ec6-8098-3c7f067e6d34] tags [storage.overprovisioning.factor] does not match new disk offering [id=637a5ded-3fba-4eda-9515-fc5218d1c905] tags [null].'}
Which makes me think that cloudstack thinks this setting is actually a tag and fails the operation.
There are no other setting or tags at the storage at this moment that might cause this.
MariaDB [cloud]> select * from storage_pool_details;
+----+---------+---------------------------------+-------+---------+
| id | pool_id | name | value | display |
+----+---------+---------------------------------+-------+---------+
| 2 | 2 | storage.overprovisioning.factor | 2.0 | 1 |
+----+---------+---------------------------------+-------+---------+
1 row in set (0.00 sec)
MariaDB [cloud]> select * from storage_pool_tags;
Empty set (0.00 sec)
STEPS TO REPRODUCE
- Deploy a VM and attach a small disk to it
- with cloudmonkey execute: update configuration name = "storage.overprovisioning.factor" value = 2.0 storageid = [target.pool.id]
- with cloudmonkey execute: migrate volume volumeid=[vol.id] storageid=[target.pool.id] newdiskofferingid=[large.disk.off.id]
EXPECTED RESULTS
I would expect that the volume is migrated with new disk offering
ACTUAL RESULTS
It fails with:
{errorcode : 431, errortext : u'Target Storage [id=26055c44-abb2-3ec6-8098-3c7f067e6d34] tags [storage.overprovisioning.factor] does not match new disk offering [id=637a5ded-3fba-4eda-9515-fc5218d1c905] tags [null].'}
which looks like the overriding overprovisiohnning setting is taken as a tag. Note that there are no tags to the pool or offering at this time that might interfere.
there is a double error here: errortext : u'Target Storage [id=26055c44-abb2-3ec6-8098-3c7f067e6d34] tags [storage.overprovisioning.factor] does not match new disk offering [id=637a5ded-3fba-4eda-9515-fc5218d1c905] tags [null].'
storage.overprovisioning.factor is regarded as tag
but also
matching seems reversed; when all off the offering tags are matched on the storage it should be ok. In this case the tags on the offering are 'null' so there should be a match.
changed the title [-]storage_pool_details overprovisiohnning settings are being picked up as a tag[/-][+]storage_pool_details overprovisioning settings are being picked up as a tag[/+]on Jul 20, 2018
Activity
DaanHoogland commentedon Jul 20, 2018
there is a double error here:
errortext : u'Target Storage [id=26055c44-abb2-3ec6-8098-3c7f067e6d34] tags [storage.overprovisioning.factor] does not match new disk offering [id=637a5ded-3fba-4eda-9515-fc5218d1c905] tags [null].'but also
[-]storage_pool_details overprovisiohnning settings are being picked up as a tag[/-][+]storage_pool_details overprovisioning settings are being picked up as a tag[/+]rafaelweingartner commentedon Jul 20, 2018
That is what I am fixing with this PR #2636.
When I first implemented this tag checking, it was not consistent.
borisstoyanov commentedon Jul 20, 2018
thanks @rafaelweingartner
yadvr commentedon Aug 14, 2018
@borisstoyanov can check if the issue is resolved with Rafaels' #2636 ?
borisstoyanov commentedon Aug 27, 2018
@rhtyd yes, smoketests are passing
yadvr commentedon Aug 27, 2018
can this issue be closed then @borisstoyanov ?
borisstoyanov commentedon Aug 27, 2018
yes, closing now. Thanks @rhtyd