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 Fri, 24 Jan 2014 15:05:38 GMT
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>
*™*

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