I came across a potential bug in the way allocators do volumes placement on storage, based on storage tags. Prachi, can you please confirm if the bug is real.
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. -Alena.
