cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alena Prokharchyk (JIRA)" <>
Subject [jira] [Created] (CLOUDSTACK-4942) StorageAllocator treats the entire metadata set stored in "storage_pool_details", as placement tags
Date Wed, 23 Oct 2013 22:42:45 GMT
Alena Prokharchyk created CLOUDSTACK-4942:

             Summary: StorageAllocator treats the entire metadata set stored in "storage_pool_details",
as placement tags
                 Key: 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,..':


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 (

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

View raw message