cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "SuichII, Christopher" <Chris.Su...@netapp.com>
Subject Re: Tags on storagePool
Date Fri, 24 Jan 2014 15:00:46 GMT
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>
> *™*


Mime
View raw message