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