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 Mon, 27 Jan 2014 14:53:31 GMT
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>
>> *™*
> 


Mime
View raw message