Hey Marcus, The main problem is that if you have a storage details row that uses the value "true", but you do not intend on this row representing a storage tag, it will be interpreted as a storage tag because its value is "true".
The current storage-tag logic assumes any row in the storage details table that has "true" for a value is a storage tag. Talk to you later On Mon, Jan 27, 2014 at 12:21 PM, Marcus Sorensen <shadow...@gmail.com>wrote: > I'm ok with whatever. It does seem like we have the ability to > differentiate real storage tags from details, since we can list/edit > those storage tags (I don't see all of my details showing up in the UI > when I look at the tags for my primary storage), though I'm not > immediately sure why or how at the moment. I think this affects Mike > the most, since he's shipping a plugin to customers. I can just look > at whatever changes are made and update my pools manually, if need be. > > On Mon, Jan 27, 2014 at 11:43 AM, Mike Tutkowski > <mike.tutkow...@solidfire.com> wrote: > > 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> > > *™* > -- *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> *™*
