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