René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"storage_pool_details overprovisioning settings are being picked up as a tag","articleBody":"\u003c!--\r\nVerify first that your issue/request is not already reported on GitHub.\r\nAlso test if the latest release and master branch are affected too.\r\nAlways add information AFTER of these HTML comments, but no need to delete the comments.\r\n--\u003e\r\n\r\n\r\n##### ISSUE TYPE\r\n\u003c!-- Pick one below and delete the rest --\u003e\r\n * Bug Report\r\n\r\n\r\n##### COMPONENT NAME\r\n\u003c!--\r\nCategorize the issue, e.g. API, VR, VPN, UI, etc.\r\n--\u003e\r\n~~~\r\nStorage\r\n~~~\r\n\r\n##### CLOUDSTACK VERSION\r\n\u003c!--\r\nNew line separated list of affected versions, commit ID for issues on master branch.\r\n--\u003e\r\n\r\n~~~\r\n4.12\r\n~~~\r\n\r\n##### SUMMARY\r\n\u003c!-- Explain the problem/feature briefly --\u003e\r\nWhen user uses the updateConfiguration api: \r\n~~~\r\nupdate configuration name = \"storage.overprovisioning.factor\" value = 2.0 storageid = [pool.id]\r\n~~~\r\nCloudstack api creates a record in the storage_pool_details table looking like that: \r\n~~~\r\nMariaDB [cloud]\u003e  select * from storage_pool_details;\r\n+----+---------+---------------------------------+-------+---------+\r\n| id | pool_id | name                            | value | display |\r\n+----+---------+---------------------------------+-------+---------+\r\n|  2 |       2 | storage.overprovisioning.factor | 2.0   |       1 |\r\n+----+---------+---------------------------------+-------+---------+\r\n1 row in set (0.00 sec)\r\n~~~\r\nAt this point if you try to migrate a volume and change it's disk offering, it fails with \r\n\r\n~~~\r\n{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].'}\r\n~~~ \r\n\r\nWhich makes me think that cloudstack thinks this setting is actually a tag and fails the operation.\r\n\r\nThere are no other setting or tags at the storage at this moment that might cause this. \r\n\r\n~~~\r\nMariaDB [cloud]\u003e  select * from storage_pool_details;\r\n+----+---------+---------------------------------+-------+---------+\r\n| id | pool_id | name                            | value | display |\r\n+----+---------+---------------------------------+-------+---------+\r\n|  2 |       2 | storage.overprovisioning.factor | 2.0   |       1 |\r\n+----+---------+---------------------------------+-------+---------+\r\n1 row in set (0.00 sec)\r\n\r\nMariaDB [cloud]\u003e  select * from storage_pool_tags;\r\nEmpty set (0.00 sec)\r\n\r\n~~~\r\n\r\n##### STEPS TO REPRODUCE\r\n\u003c!--\r\nFor bugs, show exactly how to reproduce the problem, using a minimal test-case. Use Screenshots if accurate.\r\n\r\nFor new features, show how the feature would be used.\r\n--\u003e\r\n\r\n\u003c!-- Paste example playbooks or commands between quotes below --\u003e\r\n~~~\r\n- Deploy a VM and attach a small disk to it\r\n- with cloudmonkey execute: update configuration name = \"storage.overprovisioning.factor\" value = 2.0 storageid = [target.pool.id]\r\n- with cloudmonkey execute: migrate volume volumeid=[vol.id] storageid=[target.pool.id] newdiskofferingid=[large.disk.off.id]\r\n~~~\r\n\r\n\u003c!-- You can also paste gist.github.com links for larger files --\u003e\r\n\r\n##### EXPECTED RESULTS\r\n\u003c!-- What did you expect to happen when running the steps above? --\u003e\r\n\r\n~~~\r\nI would expect that the volume is migrated with new disk offering\r\n~~~\r\n\r\n##### ACTUAL RESULTS\r\n\u003c!-- What actually happened? --\u003e\r\n\r\n\u003c!-- Paste verbatim command output between quotes below --\u003e\r\n~~~\r\nIt fails with:\r\n{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].'}\r\n\r\nwhich 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.\r\n~~~\r\n","author":{"url":"https://github.com/borisstoyanov","@type":"Person","name":"borisstoyanov"},"datePublished":"2018-07-20T13:18:01.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":7},"url":"https://github.com/2758/cloudstack/issues/2758"}