cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Tutkowski <mike.tutkow...@solidfire.com>
Subject Re: Tags on storagePool
Date Mon, 27 Jan 2014 18:43:58 GMT
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.Suich@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.suich@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.tutkowski@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.Suich@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.suich@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.Suich@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.suich@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.tutkowski@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.tutkowski@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.tutkowski@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.Suich@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.suich@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.tutkowski@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.Suich@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.suich@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.Prokharchyk@citrix.com> wrote:
> >>>>>>>>>
> >>>>>>>>>> Filed
> >>>>>>>>>>
> >>>>>>>>>> https://issues.apache.org/jira/browse/CLOUDSTACK-4942
> >>>>>>>>>>
> >>>>>>>>>> -Alena.
> >>>>>>>>>>
> >>>>>>>>>> From: Prachi Damle <Prachi.Damle@citrix.com<mailto:
> >>>>>>>>> Prachi.Damle@citrix.com>>
> >>>>>>>>>> Date: Wednesday, October 23, 2013 2:04 PM
> >>>>>>>>>> To: Alena Prokharchyk <alena.prokharchyk@citrix.com<mailto:
> >>>>>>>>> alena.prokharchyk@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*™*

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message