I think at some point we need to use a key/value for storage tags such as the following:
storageTags=value1,value2,value3 The problem with that is you have to parse the value cell each time you pull it out of the DB. That might be too risky of a change, though, for 4.3 at this point. On Fri, Jan 24, 2014 at 5:24 AM, SuichII, Christopher < chris.su...@netapp.com> wrote: > I have found an additional issue related to this. The allocators do > properly ignore any storage pool details whose value is true that is not > actually a storage pool. However, the list storage pools API does NOT. When > creating the StoragePoolResponse, it is still assumed that any storage pool > detail with the value ‘true’ is a storage tag. > > For my plugin targeting 4.3, we create a storage pool detail with a > true/false value, so this causes a problem with the storage pool UI. > > Any thoughts on how to fix this? > > -Chris > -- > Chris Suich > chris.su...@netapp.com > NetApp Software Engineer > Data Center Platforms – Cloud Solutions > Citrix, Cisco & Red Hat > > On Oct 23, 2013, at 6:43 PM, Alena Prokharchyk < > alena.prokharc...@citrix.com> wrote: > > > Filed > > > > https://issues.apache.org/jira/browse/CLOUDSTACK-4942 > > > > -Alena. > > > > From: Prachi Damle <prachi.da...@citrix.com<mailto: > prachi.da...@citrix.com>> > > Date: Wednesday, October 23, 2013 2:04 PM > > To: Alena Prokharchyk <alena.prokharc...@citrix.com<mailto: > alena.prokharc...@citrix.com>>, "dev@cloudstack.apache.org<mailto: > dev@cloudstack.apache.org>" <dev@cloudstack.apache.org<mailto: > dev@cloudstack.apache.org>> > > Subject: RE: Tags on storagePool > > > > Alena, > > > > I don’t know why it was designed this way in first place – a design like > host_tags where we have separate table to store tags is much better for > Allocators to work on. > > > > It is a bug, but will cause problem only if we land up with situation > explained below: > > > > Given the existing design of storage tags, the Allocators search the > details table using the name = <tag-provided-in-disk-offering> and value > =true > > Thus this will cause a problem in placement only if some other storage > pool detail happen to have the same ‘name’ as a storage-tag and also a > value = true. > > > > -Prachi > > > > From: Alena Prokharchyk > > Sent: Wednesday, October 23, 2013 1:36 PM > > To: Prachi Damle; dev@cloudstack.apache.org<mailto: > dev@cloudstack.apache.org> > > Subject: Tags on storagePool > > > > 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> *™*
