This isn't a great solution, but you could also change the value for your plug-in from true or false to something like t or f.
On Fri, Jan 24, 2014 at 8:08 AM, Mike Tutkowski < mike.tutkow...@solidfire.com> wrote: > Edison could confirm this perhaps, but I doubt any current installation > would have true for the value unless it was for a storage tag (the plug-in > framework just came out in 4.2). > > > On Fri, Jan 24, 2014 at 8:05 AM, Mike Tutkowski < > mike.tutkow...@solidfire.com> wrote: > >> I think your idea would be acceptable risk for 4.3. The upgrade logic >> would have to perform this true-to-storage_tag conversion, too, though. >> >> >> On Fri, Jan 24, 2014 at 8:00 AM, SuichII, Christopher < >> chris.su...@netapp.com> wrote: >> >>> I think the quickest, easiest change would be to keep using the tag name >>> as the key in the details table, but use a unique value like ‘storage_tag’ >>> instead of ‘true’. This wouldn’t require any major logic changes, just the >>> value used to check whether something is a storage tag. >>> >>> It is quite risky for 4.3. However my concern is that if we let this >>> ship with 4.3, then any plugin that wants to use a storage pool detail with >>> the value ‘true’ will make updating the storage tag system MUCH more >>> difficult. As far as I can tell, there is no other way to determine if >>> something is a storage tag than checking if the details table value is >>> ‘true’. If there are other details with the value ‘true’, then we wouldn’t >>> be able to differentiate between them for a DB upgrade between versions. >>> >>> -Chris >>> -- >>> Chris Suich >>> chris.su...@netapp.com >>> NetApp Software Engineer >>> Data Center Platforms – Cloud Solutions >>> Citrix, Cisco & Red Hat >>> >>> On Jan 24, 2014, at 9:53 AM, Mike Tutkowski < >>> mike.tutkow...@solidfire.com> wrote: >>> >>> > 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> >>> > *™* >>> >>> >> >> >> -- >> *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> >> *™* >> > > > > -- > *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> > *™* > -- *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> *™*
