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> *™*
