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 15:33:41 GMT
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>
*™*

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