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 19:26:59 GMT
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 <shadowsor@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.tutkowski@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.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>
> > *™*
>



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