I think my only real concern with working around it in this manner is that once a fix is applied, we now have a bunch of settings that do not conform to the true/false pattern. In order to migrate them from using t/f, yes/no or enabled/disabled back to using true/false, we would have to write some kind of DB upgrade/migration in our plugin to update these values. In addition, I would have to change the ConfigKey from being a boolean to a string and then back to a boolean once a solution is implemented. It is just some technical debt that would pile up for plugins with a pretty nasty fix down the road.
-Chris -- Chris Suich chris.su...@netapp.com NetApp Software Engineer Data Center Platforms – Cloud Solutions Citrix, Cisco & Red Hat On Jan 27, 2014, at 10:33 AM, Mike Tutkowski <mike.tutkow...@solidfire.com> wrote: > It is a problem, but I think - at the moment - only NetApp, SolidFire, and > Marcus have storage plug-ins. > > We could document this issue and the easy workaround of not using true and > false as a value and try to address it in 4.4. > > > On Mon, Jan 27, 2014 at 7:53 AM, SuichII, Christopher < > chris.su...@netapp.com> wrote: > >> Any final thoughts on this? Letting this go into 4.3 could potentially >> cause issues with anyone using the configuration system for plugins in 4.3. >> >> -Chris >> -- >> Chris Suich >> chris.su...@netapp.com >> NetApp Software Engineer >> Data Center Platforms – Cloud Solutions >> Citrix, Cisco & Red Hat >> >> On Jan 24, 2014, at 3:34 PM, SuichII, Christopher <chris.su...@netapp.com> >> wrote: >> >>> This is the approach we’ll have to take if we can’t fix this in 4.3. It >> certainly works, but it isn’t ideal. >>> >>> Does anyone else have any thoughts on the impact this might have to 4.3? >>> >>> -Chris >>> -- >>> Chris Suich >>> chris.su...@netapp.com >>> NetApp Software Engineer >>> Data Center Platforms – Cloud Solutions >>> Citrix, Cisco & Red Hat >>> >>> On Jan 24, 2014, at 10:11 AM, Mike Tutkowski < >> mike.tutkow...@solidfire.com> wrote: >>> >>>> 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> >>>> *™* >>> >> >> > > > -- > *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> > *™*
