I agree...it certainly is not an ideal situation. Have you assessed the risk involved with changing storage tags from using true as a value to using something like storage_tag as a value?
If so, do you feel it is an acceptable amount of risk for 4.3 now that we have already begun spinning up RC builds? Thanks On Mon, Jan 27, 2014 at 8:40 AM, SuichII, Christopher < chris.su...@netapp.com> wrote: > 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> > > *™* > > -- *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> *™*
