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 12:24:26 GMT
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.
> 


Mime
View raw message