I agree - this is a bug. We should not assume because a value is true that the name is a storage tag.
On Wed, Oct 23, 2013 at 2:36 PM, Alena Prokharchyk < alena.prokharc...@citrix.com> wrote: > 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. > > -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud<http://solidfire.com/solution/overview/?video=play> *™*
