Alena Prokharchyk created CLOUDSTACK-4942:
---------------------------------------------
Summary: StorageAllocator treats the entire metadata set stored in
"storage_pool_details", as placement tags
Key: CLOUDSTACK-4942
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4942
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: Management Server
Affects Versions: 4.2.0
Reporter: Alena Prokharchyk
Priority: Critical
Fix For: Future
There is a bug in the way allocators do volumes placement on storage, based on
storage tags.
The tags are passed to the createStoragePool API in form of tags='tag1,tag2,..':
?command=createStoragePool&...&tags=alena
and stored in the storage_pool_details db table as:
mysql> select *from storage_pool_details where pool_id=2;
+----+---------+-----------+-------+
| id | pool_id | name | value |
+----+---------+-----------+-------+
| 2 | 2 | alenatags | true |
+----+---------+-----------+-------+
1 row in set (0.00 sec)
Allocator code assumes that everything stored in storage_pool_details table,
having value=true - is a storage pool tag. And this is incorrect, as the
storage_pool_details table is used for storing diff kinds of storage pool
details - not just tags - that can be later used by various cloudStack
managers. Like for example we save Storage level config parameters in this
table
(https://cwiki.apache.org/confluence/display/CLOUDSTACK/FS+for+Granular+Global+Configuration+Parameters).
The correct way to fix it would be - store tags as:
+----+---------+-----------+-------+
| id | pool_id | name | value |
+----+---------+-----------+-------+
| 2 | 2 | tag | alena |
+----+---------+-----------+-------+
and fix StorageManager to retrive all the tags by the "tag" key. We also have
to fix the DB upgrade, which can be tricky as we will have to figure out which
detail is a tag.
--
This message was sent by Atlassian JIRA
(v6.1#6144)