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