-
From: Marcus Sorensen [mailto:shadow...@gmail.com]
Sent: Monday, January 27, 2014 11:32 AM
To: dev@cloudstack.apache.org
Subject: Re: Tags on storagePool
Right, for some reason I was thinking in the moment that all details would have
a value of 'true'. Since that's not the case,
st_tag and also upgrade steps for existing storage tags present
> in the details.
>
> Prachi
>
>
> -Original Message-
> From: Marcus Sorensen [mailto:shadow...@gmail.com]
> Sent: Monday, January 27, 2014 11:32 AM
> To: dev@cloudstack.apache.org
> Subject: Re: Tag
t;>>>>>> 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
>> >>>
;>>>>> be able to differentiate between them for a DB upgrade between
> >>>>> versions.
> >>>>>>>>>>
> >>>>>>>>>> -Chris
> >>>>>>>>>> --
> >>>>>>>>>> C
t; -Chris
>>>>>>>>>> --
>>>>>>>>>> Chris Suich
>>>>>>>>>> chris.su...@netapp.com
>>>>>>>>>> NetApp Software Engineer
>>>>>>>>>> Data Center Platforms – Cloud So
>>> Data Center Platforms – Cloud Solutions
> >> >>>>>>> Citrix, Cisco & Red Hat
> >> >>>>>>>
> >> >>>>>>> On Jan 24, 2014, at 9:53 AM, Mike Tutkowski <
> >> >>>>>>&
t;> I think at some point we need to use a key/value for storage tags
>> >> such
>> >>>>>>> as
>> >>>>>>>> the following:
>> >>>>>>>>
>> >>>>>>>> storageTags=value1,value2,valu
;>>>> 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.
> >>>&g
>>>>>>>> On Fri, Jan 24, 2014 at 5:24 AM, SuichII, Christopher <
>>>>>>>> chris.su...@netapp.com> wrote:
>>>>>>>>
>>>>>>>>> I have found an additional issue related to this. The allocator
rly 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 StoragePoo
gt;>>> 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
gt;>> 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.
>>>>>>
>
>>
>>> >> -Chris
>>> >> --
>>> >> Chris Suich
>>> >> chris.su...@netapp.com
>>> >> NetApp Software Engineer
>>> >> Data Center Platforms – Cloud Solutions
>>> >> Citrix, Cisco & Red Hat
>>&
; >> Any thoughts on how to fix this?
>> >>
>> >> -Chris
>> >> --
>> >> Chris Suich
>> >> chris.su...@netapp.com
>> >> NetApp Software Engineer
>> >> Data Center Platforms – Cloud Solutions
>> >
latforms – Cloud Solutions
> >> Citrix, Cisco & Red Hat
> >>
> >> On Oct 23, 2013, at 6:43 PM, Alena Prokharchyk <
> >> alena.prokharc...@citrix.com> wrote:
> >>
> >>> Filed
> >>>
> >>> https://issues.apache.org/jir
; Filed
>>>
>>> https://issues.apache.org/jira/browse/CLOUDSTACK-4942
>>>
>>> -Alena.
>>>
>>> From: Prachi Damle > prachi.da...@citrix.com>>
>>> Date: Wednesday, October 23, 2013 2:04 PM
>>> To: Alena Prokharch
okharchyk alena.prokharc...@citrix.com>>, "dev@cloudstack.apache.org dev@cloudstack.apache.org>" dev@cloudstack.apache.org>>
> > Subject: RE: Tags on storagePool
> >
> > Alena,
> >
> > I don’t know why it was designed this way in first p
day, October 23, 2013 2:04 PM
> To: Alena Prokharchyk
> mailto:alena.prokharc...@citrix.com>>,
> "dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>"
> mailto:dev@cloudstack.apache.org>>
> Subject: RE: Tags on storagePool
>
> Alena,
>
&
loudstack.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 wil
Sent: Wednesday, October 23, 2013 1:36 PM
To: Prachi Damle; 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 ar
If someone logs a JIRA ticket on this, please note that the
updateStoragePool command would need to be corrected, as well, because it
has special knowledge of a true value meaning that the name is a storage
tag.
On Wed, Oct 23, 2013 at 2:45 PM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote
I agree - this is a bug.
We should not assume because a value is true that the name is a storage tag.
On Wed, Oct 23, 2013 at 2:36 PM, Alena Prokharchyk <
alena.prokharc...@citrix.com> wrote:
> I came across a potential bug in the way allocators do volumes placement
> on storage, based on stora
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
23 matches
Mail list logo
