You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by John Burwell <jb...@basho.com> on 2013/07/19 22:30:27 UTC
[ACS42] NFS Cache Naming
All,
It was my understanding that we had agreed to rename the "NFS Cache" mechanism to reflect that it is not a cache and remove the assumption that it will always be backed by NFS. Is my understanding correct?
Thanks,
-John
Re: [ACS42] NFS Cache Naming
Posted by Min Chen <mi...@citrix.com>.
CLOUDSTACK-3818 is resolved now based on our consensus.
Thanks
-min
On 7/26/13 11:33 AM, "John Burwell" <jb...@basho.com> wrote:
>Works for me -- +1.
>On Jul 26, 2013, at 2:23 PM, Min Chen <mi...@citrix.com> wrote:
>
>> I like this better, they will be replaced as below if there is no
>> objection.
>>
>> createSecondaryStagingStore
>> listSecondaryStagingStores
>> deleteSecondaryStagingStore
>>
>> Jessica, please fix the UI invocation with these new api names. API
>> parameters are not changed, just name is changed.
>>
>> Thanks
>> -min
>>
>> On 7/26/13 11:19 AM, "Chip Childers" <ch...@sungard.com> wrote:
>>
>>> Daan answered that below with "NFS Staging", so refining that a bit,
>>> here's my proposal:
>>>
>>> fooSecondaryStagingStore
>>>
>>>
>>> On Fri, Jul 26, 2013 at 06:15:04PM +0000, Min Chen wrote:
>>>> John,
>>>>
>>>> Currently we have 3 APIs for previous cache store, they are named as:
>>>> createCacheStore
>>>> listCacheStores
>>>> deleteCacheStore
>>>>
>>>> What are your preferred names for these 3 APIs? Let's get a consensus
>>>> before I change it to be more effective.
>>>>
>>>> Thanks
>>>> -min
>>>>
>>>> From: John Burwell <jb...@basho.com>>
>>>> Date: Friday, July 26, 2013 9:43 AM
>>>> To: Min Chen <mi...@citrix.com>>
>>>> Cc: Daan Hoogland
>>>> <da...@gmail.com>>, dev
>>>> <de...@cloudstack.apache.org>>, Edison
>>>>Su
>>>> <Ed...@citrix.com>>
>>>> Subject: Re: [ACS42] NFS Cache Naming
>>>>
>>>> Min,
>>>>
>>>> That is my recommendation with a task ticket to make the consistent
>>>> post 4.2.0.
>>>>
>>>> Thanks,
>>>> -John
>>>>
>>>> On Jul 26, 2013, at 12:42 PM, Min Chen
>>>> <mi...@citrix.com>> wrote:
>>>>
>>>> So from your email below, the consensus is to fix user visible
>>>>elements
>>>> (UI, API, Configuration, Documentation) in 4.2, I will address that
>>>>bug
>>>> based on this understanding.
>>>>
>>>> Thanks for your clarification.
>>>> -min
>>>>
>>>> From: John Burwell <jb...@basho.com>>
>>>> Date: Friday, July 26, 2013 9:38 AM
>>>> To: Min Chen <mi...@citrix.com>>
>>>> Cc: Daan Hoogland
>>>> <da...@gmail.com>>, dev
>>>> <de...@cloudstack.apache.org>>, Edison
>>>>Su
>>>> <Ed...@citrix.com>>
>>>> Subject: Re: [ACS42] NFS Cache Naming
>>>>
>>>> Min,
>>>>
>>>> In my opinion, it is a blocker because it is very misleading to
>>>> operations, and once the name ships in documentation/UI/APIs it will
>>>> essentially irreversible. Furthermore, as a community, we agreed to
>>>> make this change in late May/early June. In view, community decisions
>>>> for a release that are not carried in a release should become a
>>>>blocker.
>>>>
>>>> I added a comment the following comment to the ticket which, I hope,
>>>> will answer your question:
>>>>
>>>> Min,
>>>>
>>>> Ideally, both. However, given the short window, the priority is for
>>>>all
>>>> user visible elements (e.g. API, UI, configuration files,
>>>>documentation,
>>>> etc).
>>>>
>>>> If we do not have time address code, please open a task ticket to
>>>> refactor the naming internally for post-4.2.0 work.
>>>>
>>>> Thanks,
>>>> -John
>>>>
>>>> Thanks,
>>>> -John
>>>>
>>>> On Jul 26, 2013, at 12:31 PM, Min Chen
>>>> <mi...@citrix.com>> wrote:
>>>>
>>>> Hi John,
>>>>
>>>> I saw the blocker defect filed by you regarding this Nomenclature
>>>> issue(https://issues.apache.org/jira/browse/CLOUDSTACK-3818). Honestly
>>>> speaking, this does not qualify as a BLOCKER since it is not blocking
>>>> any functionality. One question I commented on the bug is: do you want
>>>> to change our UI to call out as "Staging Storage" wherever we have
>>>>Cache
>>>> Storage showing up? Or you want us to change all our internal code
>>>>class
>>>> and method name (like needCacheStorage, etc) to use a different
>>>> class/method name? We can do former quite easily, for latter, I don't
>>>> think that it is that urgent compared to fixing other real functional
>>>> blockers and criticals for 4.2 release, since that is internal
>>>> implementation which will be totally shielded from CloudStack user.
>>>> Please share your thoughts on this.
>>>>
>>>> Thanks
>>>> -min
>>>>
>>>> From: Daan Hoogland
>>>> <da...@gmail.com>>
>>>> Date: Saturday, July 20, 2013 3:18 AM
>>>> To: dev <de...@cloudstack.apache.org>>
>>>> Cc: Edison Su <Ed...@citrix.com>>, Min
>>>> Chen <mi...@citrix.com>>
>>>> Subject: Re: [ACS42] NFS Cache Naming
>>>>
>>>> NFS Staging it was in my recollection.
>>>>
>>>>
>>>> On Fri, Jul 19, 2013 at 10:30 PM, John Burwell
>>>> <jb...@basho.com>> wrote:
>>>> All,
>>>>
>>>> It was my understanding that we had agreed to rename the "NFS Cache"
>>>> mechanism to reflect that it is not a cache and remove the assumption
>>>> that it will always be backed by NFS. Is my understanding correct?
>>>>
>>>> Thanks,
>>>> -John
>>>>
>>>>
>>>>
>>
>
Re: [ACS42] NFS Cache Naming
Posted by John Burwell <jb...@basho.com>.
Works for me -- +1.
On Jul 26, 2013, at 2:23 PM, Min Chen <mi...@citrix.com> wrote:
> I like this better, they will be replaced as below if there is no
> objection.
>
> createSecondaryStagingStore
> listSecondaryStagingStores
> deleteSecondaryStagingStore
>
> Jessica, please fix the UI invocation with these new api names. API
> parameters are not changed, just name is changed.
>
> Thanks
> -min
>
> On 7/26/13 11:19 AM, "Chip Childers" <ch...@sungard.com> wrote:
>
>> Daan answered that below with "NFS Staging", so refining that a bit,
>> here's my proposal:
>>
>> fooSecondaryStagingStore
>>
>>
>> On Fri, Jul 26, 2013 at 06:15:04PM +0000, Min Chen wrote:
>>> John,
>>>
>>> Currently we have 3 APIs for previous cache store, they are named as:
>>> createCacheStore
>>> listCacheStores
>>> deleteCacheStore
>>>
>>> What are your preferred names for these 3 APIs? Let's get a consensus
>>> before I change it to be more effective.
>>>
>>> Thanks
>>> -min
>>>
>>> From: John Burwell <jb...@basho.com>>
>>> Date: Friday, July 26, 2013 9:43 AM
>>> To: Min Chen <mi...@citrix.com>>
>>> Cc: Daan Hoogland
>>> <da...@gmail.com>>, dev
>>> <de...@cloudstack.apache.org>>, Edison Su
>>> <Ed...@citrix.com>>
>>> Subject: Re: [ACS42] NFS Cache Naming
>>>
>>> Min,
>>>
>>> That is my recommendation with a task ticket to make the consistent
>>> post 4.2.0.
>>>
>>> Thanks,
>>> -John
>>>
>>> On Jul 26, 2013, at 12:42 PM, Min Chen
>>> <mi...@citrix.com>> wrote:
>>>
>>> So from your email below, the consensus is to fix user visible elements
>>> (UI, API, Configuration, Documentation) in 4.2, I will address that bug
>>> based on this understanding.
>>>
>>> Thanks for your clarification.
>>> -min
>>>
>>> From: John Burwell <jb...@basho.com>>
>>> Date: Friday, July 26, 2013 9:38 AM
>>> To: Min Chen <mi...@citrix.com>>
>>> Cc: Daan Hoogland
>>> <da...@gmail.com>>, dev
>>> <de...@cloudstack.apache.org>>, Edison Su
>>> <Ed...@citrix.com>>
>>> Subject: Re: [ACS42] NFS Cache Naming
>>>
>>> Min,
>>>
>>> In my opinion, it is a blocker because it is very misleading to
>>> operations, and once the name ships in documentation/UI/APIs it will
>>> essentially irreversible. Furthermore, as a community, we agreed to
>>> make this change in late May/early June. In view, community decisions
>>> for a release that are not carried in a release should become a blocker.
>>>
>>> I added a comment the following comment to the ticket which, I hope,
>>> will answer your question:
>>>
>>> Min,
>>>
>>> Ideally, both. However, given the short window, the priority is for all
>>> user visible elements (e.g. API, UI, configuration files, documentation,
>>> etc).
>>>
>>> If we do not have time address code, please open a task ticket to
>>> refactor the naming internally for post-4.2.0 work.
>>>
>>> Thanks,
>>> -John
>>>
>>> Thanks,
>>> -John
>>>
>>> On Jul 26, 2013, at 12:31 PM, Min Chen
>>> <mi...@citrix.com>> wrote:
>>>
>>> Hi John,
>>>
>>> I saw the blocker defect filed by you regarding this Nomenclature
>>> issue(https://issues.apache.org/jira/browse/CLOUDSTACK-3818). Honestly
>>> speaking, this does not qualify as a BLOCKER since it is not blocking
>>> any functionality. One question I commented on the bug is: do you want
>>> to change our UI to call out as "Staging Storage" wherever we have Cache
>>> Storage showing up? Or you want us to change all our internal code class
>>> and method name (like needCacheStorage, etc) to use a different
>>> class/method name? We can do former quite easily, for latter, I don't
>>> think that it is that urgent compared to fixing other real functional
>>> blockers and criticals for 4.2 release, since that is internal
>>> implementation which will be totally shielded from CloudStack user.
>>> Please share your thoughts on this.
>>>
>>> Thanks
>>> -min
>>>
>>> From: Daan Hoogland
>>> <da...@gmail.com>>
>>> Date: Saturday, July 20, 2013 3:18 AM
>>> To: dev <de...@cloudstack.apache.org>>
>>> Cc: Edison Su <Ed...@citrix.com>>, Min
>>> Chen <mi...@citrix.com>>
>>> Subject: Re: [ACS42] NFS Cache Naming
>>>
>>> NFS Staging it was in my recollection.
>>>
>>>
>>> On Fri, Jul 19, 2013 at 10:30 PM, John Burwell
>>> <jb...@basho.com>> wrote:
>>> All,
>>>
>>> It was my understanding that we had agreed to rename the "NFS Cache"
>>> mechanism to reflect that it is not a cache and remove the assumption
>>> that it will always be backed by NFS. Is my understanding correct?
>>>
>>> Thanks,
>>> -John
>>>
>>>
>>>
>
Re: [ACS42] NFS Cache Naming
Posted by Min Chen <mi...@citrix.com>.
I like this better, they will be replaced as below if there is no
objection.
createSecondaryStagingStore
listSecondaryStagingStores
deleteSecondaryStagingStore
Jessica, please fix the UI invocation with these new api names. API
parameters are not changed, just name is changed.
Thanks
-min
On 7/26/13 11:19 AM, "Chip Childers" <ch...@sungard.com> wrote:
>Daan answered that below with "NFS Staging", so refining that a bit,
>here's my proposal:
>
>fooSecondaryStagingStore
>
>
>On Fri, Jul 26, 2013 at 06:15:04PM +0000, Min Chen wrote:
>> John,
>>
>> Currently we have 3 APIs for previous cache store, they are named as:
>> createCacheStore
>> listCacheStores
>> deleteCacheStore
>>
>> What are your preferred names for these 3 APIs? Let's get a consensus
>>before I change it to be more effective.
>>
>> Thanks
>> -min
>>
>> From: John Burwell <jb...@basho.com>>
>> Date: Friday, July 26, 2013 9:43 AM
>> To: Min Chen <mi...@citrix.com>>
>> Cc: Daan Hoogland
>><da...@gmail.com>>, dev
>><de...@cloudstack.apache.org>>, Edison Su
>><Ed...@citrix.com>>
>> Subject: Re: [ACS42] NFS Cache Naming
>>
>> Min,
>>
>> That is my recommendation with a task ticket to make the consistent
>>post 4.2.0.
>>
>> Thanks,
>> -John
>>
>> On Jul 26, 2013, at 12:42 PM, Min Chen
>><mi...@citrix.com>> wrote:
>>
>> So from your email below, the consensus is to fix user visible elements
>>(UI, API, Configuration, Documentation) in 4.2, I will address that bug
>>based on this understanding.
>>
>> Thanks for your clarification.
>> -min
>>
>> From: John Burwell <jb...@basho.com>>
>> Date: Friday, July 26, 2013 9:38 AM
>> To: Min Chen <mi...@citrix.com>>
>> Cc: Daan Hoogland
>><da...@gmail.com>>, dev
>><de...@cloudstack.apache.org>>, Edison Su
>><Ed...@citrix.com>>
>> Subject: Re: [ACS42] NFS Cache Naming
>>
>> Min,
>>
>> In my opinion, it is a blocker because it is very misleading to
>>operations, and once the name ships in documentation/UI/APIs it will
>>essentially irreversible. Furthermore, as a community, we agreed to
>>make this change in late May/early June. In view, community decisions
>>for a release that are not carried in a release should become a blocker.
>>
>> I added a comment the following comment to the ticket which, I hope,
>>will answer your question:
>>
>> Min,
>>
>> Ideally, both. However, given the short window, the priority is for all
>>user visible elements (e.g. API, UI, configuration files, documentation,
>>etc).
>>
>> If we do not have time address code, please open a task ticket to
>>refactor the naming internally for post-4.2.0 work.
>>
>> Thanks,
>> -John
>>
>> Thanks,
>> -John
>>
>> On Jul 26, 2013, at 12:31 PM, Min Chen
>><mi...@citrix.com>> wrote:
>>
>> Hi John,
>>
>> I saw the blocker defect filed by you regarding this Nomenclature
>>issue(https://issues.apache.org/jira/browse/CLOUDSTACK-3818). Honestly
>>speaking, this does not qualify as a BLOCKER since it is not blocking
>>any functionality. One question I commented on the bug is: do you want
>>to change our UI to call out as "Staging Storage" wherever we have Cache
>>Storage showing up? Or you want us to change all our internal code class
>>and method name (like needCacheStorage, etc) to use a different
>>class/method name? We can do former quite easily, for latter, I don't
>>think that it is that urgent compared to fixing other real functional
>>blockers and criticals for 4.2 release, since that is internal
>>implementation which will be totally shielded from CloudStack user.
>> Please share your thoughts on this.
>>
>> Thanks
>> -min
>>
>> From: Daan Hoogland
>><da...@gmail.com>>
>> Date: Saturday, July 20, 2013 3:18 AM
>> To: dev <de...@cloudstack.apache.org>>
>> Cc: Edison Su <Ed...@citrix.com>>, Min
>>Chen <mi...@citrix.com>>
>> Subject: Re: [ACS42] NFS Cache Naming
>>
>> NFS Staging it was in my recollection.
>>
>>
>> On Fri, Jul 19, 2013 at 10:30 PM, John Burwell
>><jb...@basho.com>> wrote:
>> All,
>>
>> It was my understanding that we had agreed to rename the "NFS Cache"
>>mechanism to reflect that it is not a cache and remove the assumption
>>that it will always be backed by NFS. Is my understanding correct?
>>
>> Thanks,
>> -John
>>
>>
>>
Re: [ACS42] NFS Cache Naming
Posted by Chip Childers <ch...@sungard.com>.
Daan answered that below with "NFS Staging", so refining that a bit,
here's my proposal:
fooSecondaryStagingStore
On Fri, Jul 26, 2013 at 06:15:04PM +0000, Min Chen wrote:
> John,
>
> Currently we have 3 APIs for previous cache store, they are named as:
> createCacheStore
> listCacheStores
> deleteCacheStore
>
> What are your preferred names for these 3 APIs? Let's get a consensus before I change it to be more effective.
>
> Thanks
> -min
>
> From: John Burwell <jb...@basho.com>>
> Date: Friday, July 26, 2013 9:43 AM
> To: Min Chen <mi...@citrix.com>>
> Cc: Daan Hoogland <da...@gmail.com>>, dev <de...@cloudstack.apache.org>>, Edison Su <Ed...@citrix.com>>
> Subject: Re: [ACS42] NFS Cache Naming
>
> Min,
>
> That is my recommendation with a task ticket to make the consistent post 4.2.0.
>
> Thanks,
> -John
>
> On Jul 26, 2013, at 12:42 PM, Min Chen <mi...@citrix.com>> wrote:
>
> So from your email below, the consensus is to fix user visible elements (UI, API, Configuration, Documentation) in 4.2, I will address that bug based on this understanding.
>
> Thanks for your clarification.
> -min
>
> From: John Burwell <jb...@basho.com>>
> Date: Friday, July 26, 2013 9:38 AM
> To: Min Chen <mi...@citrix.com>>
> Cc: Daan Hoogland <da...@gmail.com>>, dev <de...@cloudstack.apache.org>>, Edison Su <Ed...@citrix.com>>
> Subject: Re: [ACS42] NFS Cache Naming
>
> Min,
>
> In my opinion, it is a blocker because it is very misleading to operations, and once the name ships in documentation/UI/APIs it will essentially irreversible. Furthermore, as a community, we agreed to make this change in late May/early June. In view, community decisions for a release that are not carried in a release should become a blocker.
>
> I added a comment the following comment to the ticket which, I hope, will answer your question:
>
> Min,
>
> Ideally, both. However, given the short window, the priority is for all user visible elements (e.g. API, UI, configuration files, documentation, etc).
>
> If we do not have time address code, please open a task ticket to refactor the naming internally for post-4.2.0 work.
>
> Thanks,
> -John
>
> Thanks,
> -John
>
> On Jul 26, 2013, at 12:31 PM, Min Chen <mi...@citrix.com>> wrote:
>
> Hi John,
>
> I saw the blocker defect filed by you regarding this Nomenclature issue(https://issues.apache.org/jira/browse/CLOUDSTACK-3818). Honestly speaking, this does not qualify as a BLOCKER since it is not blocking any functionality. One question I commented on the bug is: do you want to change our UI to call out as "Staging Storage" wherever we have Cache Storage showing up? Or you want us to change all our internal code class and method name (like needCacheStorage, etc) to use a different class/method name? We can do former quite easily, for latter, I don't think that it is that urgent compared to fixing other real functional blockers and criticals for 4.2 release, since that is internal implementation which will be totally shielded from CloudStack user.
> Please share your thoughts on this.
>
> Thanks
> -min
>
> From: Daan Hoogland <da...@gmail.com>>
> Date: Saturday, July 20, 2013 3:18 AM
> To: dev <de...@cloudstack.apache.org>>
> Cc: Edison Su <Ed...@citrix.com>>, Min Chen <mi...@citrix.com>>
> Subject: Re: [ACS42] NFS Cache Naming
>
> NFS Staging it was in my recollection.
>
>
> On Fri, Jul 19, 2013 at 10:30 PM, John Burwell <jb...@basho.com>> wrote:
> All,
>
> It was my understanding that we had agreed to rename the "NFS Cache" mechanism to reflect that it is not a cache and remove the assumption that it will always be backed by NFS. Is my understanding correct?
>
> Thanks,
> -John
>
>
>
Re: [ACS42] NFS Cache Naming
Posted by Chip Childers <ch...@sungard.com>.
On Fri, Jul 26, 2013 at 02:18:43PM -0400, John Burwell wrote:
> Min,
>
> If we are agreed on the term "Staging Area", I would go with *StagingArea(s) instance of *CacheStore(s). Does that make sense?
If the only purpose of this is for secondary storage, shouldn't it be
SecondaryStaging?
>
> Thanks,
> -John
>
> On Jul 26, 2013, at 2:15 PM, Min Chen <mi...@citrix.com> wrote:
>
> > John,
> >
> > Currently we have 3 APIs for previous cache store, they are named as:
> > createCacheStore
> > listCacheStores
> > deleteCacheStore
> >
> > What are your preferred names for these 3 APIs? Let's get a consensus before I change it to be more effective.
> >
> > Thanks
> > -min
> >
> > From: John Burwell <jb...@basho.com>
> > Date: Friday, July 26, 2013 9:43 AM
> > To: Min Chen <mi...@citrix.com>
> > Cc: Daan Hoogland <da...@gmail.com>, dev <de...@cloudstack.apache.org>, Edison Su <Ed...@citrix.com>
> > Subject: Re: [ACS42] NFS Cache Naming
> >
> > Min,
> >
> > That is my recommendation with a task ticket to make the consistent post 4.2.0.
> >
> > Thanks,
> > -John
> >
> > On Jul 26, 2013, at 12:42 PM, Min Chen <mi...@citrix.com> wrote:
> >
> >> So from your email below, the consensus is to fix user visible elements (UI, API, Configuration, Documentation) in 4.2, I will address that bug based on this understanding.
> >>
> >> Thanks for your clarification.
> >> -min
> >>
> >> From: John Burwell <jb...@basho.com>
> >> Date: Friday, July 26, 2013 9:38 AM
> >> To: Min Chen <mi...@citrix.com>
> >> Cc: Daan Hoogland <da...@gmail.com>, dev <de...@cloudstack.apache.org>, Edison Su <Ed...@citrix.com>
> >> Subject: Re: [ACS42] NFS Cache Naming
> >>
> >> Min,
> >>
> >> In my opinion, it is a blocker because it is very misleading to operations, and once the name ships in documentation/UI/APIs it will essentially irreversible. Furthermore, as a community, we agreed to make this change in late May/early June. In view, community decisions for a release that are not carried in a release should become a blocker.
> >>
> >> I added a comment the following comment to the ticket which, I hope, will answer your question:
> >>
> >>> Min,
> >>>
> >>> Ideally, both. However, given the short window, the priority is for all user visible elements (e.g. API, UI, configuration files, documentation, etc).
> >>>
> >>> If we do not have time address code, please open a task ticket to refactor the naming internally for post-4.2.0 work.
> >>>
> >>> Thanks,
> >>> -John
> >>
> >>
> >> Thanks,
> >> -John
> >>
> >> On Jul 26, 2013, at 12:31 PM, Min Chen <mi...@citrix.com> wrote:
> >>
> >>> Hi John,
> >>>
> >>> I saw the blocker defect filed by you regarding this Nomenclature issue(https://issues.apache.org/jira/browse/CLOUDSTACK-3818). Honestly speaking, this does not qualify as a BLOCKER since it is not blocking any functionality. One question I commented on the bug is: do you want to change our UI to call out as "Staging Storage" wherever we have Cache Storage showing up? Or you want us to change all our internal code class and method name (like needCacheStorage, etc) to use a different class/method name? We can do former quite easily, for latter, I don't think that it is that urgent compared to fixing other real functional blockers and criticals for 4.2 release, since that is internal implementation which will be totally shielded from CloudStack user.
> >>> Please share your thoughts on this.
> >>>
> >>> Thanks
> >>> -min
> >>>
> >>> From: Daan Hoogland <da...@gmail.com>
> >>> Date: Saturday, July 20, 2013 3:18 AM
> >>> To: dev <de...@cloudstack.apache.org>
> >>> Cc: Edison Su <Ed...@citrix.com>, Min Chen <mi...@citrix.com>
> >>> Subject: Re: [ACS42] NFS Cache Naming
> >>>
> >>> NFS Staging it was in my recollection.
> >>>
> >>>
> >>> On Fri, Jul 19, 2013 at 10:30 PM, John Burwell <jb...@basho.com> wrote:
> >>>> All,
> >>>>
> >>>> It was my understanding that we had agreed to rename the "NFS Cache" mechanism to reflect that it is not a cache and remove the assumption that it will always be backed by NFS. Is my understanding correct?
> >>>>
> >>>> Thanks,
> >>>> -John
> >>>
> >>
> >
>
Re: [ACS42] NFS Cache Naming
Posted by John Burwell <jb...@basho.com>.
Min,
If we are agreed on the term "Staging Area", I would go with *StagingArea(s) instance of *CacheStore(s). Does that make sense?
Thanks,
-John
On Jul 26, 2013, at 2:15 PM, Min Chen <mi...@citrix.com> wrote:
> John,
>
> Currently we have 3 APIs for previous cache store, they are named as:
> createCacheStore
> listCacheStores
> deleteCacheStore
>
> What are your preferred names for these 3 APIs? Let's get a consensus before I change it to be more effective.
>
> Thanks
> -min
>
> From: John Burwell <jb...@basho.com>
> Date: Friday, July 26, 2013 9:43 AM
> To: Min Chen <mi...@citrix.com>
> Cc: Daan Hoogland <da...@gmail.com>, dev <de...@cloudstack.apache.org>, Edison Su <Ed...@citrix.com>
> Subject: Re: [ACS42] NFS Cache Naming
>
> Min,
>
> That is my recommendation with a task ticket to make the consistent post 4.2.0.
>
> Thanks,
> -John
>
> On Jul 26, 2013, at 12:42 PM, Min Chen <mi...@citrix.com> wrote:
>
>> So from your email below, the consensus is to fix user visible elements (UI, API, Configuration, Documentation) in 4.2, I will address that bug based on this understanding.
>>
>> Thanks for your clarification.
>> -min
>>
>> From: John Burwell <jb...@basho.com>
>> Date: Friday, July 26, 2013 9:38 AM
>> To: Min Chen <mi...@citrix.com>
>> Cc: Daan Hoogland <da...@gmail.com>, dev <de...@cloudstack.apache.org>, Edison Su <Ed...@citrix.com>
>> Subject: Re: [ACS42] NFS Cache Naming
>>
>> Min,
>>
>> In my opinion, it is a blocker because it is very misleading to operations, and once the name ships in documentation/UI/APIs it will essentially irreversible. Furthermore, as a community, we agreed to make this change in late May/early June. In view, community decisions for a release that are not carried in a release should become a blocker.
>>
>> I added a comment the following comment to the ticket which, I hope, will answer your question:
>>
>>> Min,
>>>
>>> Ideally, both. However, given the short window, the priority is for all user visible elements (e.g. API, UI, configuration files, documentation, etc).
>>>
>>> If we do not have time address code, please open a task ticket to refactor the naming internally for post-4.2.0 work.
>>>
>>> Thanks,
>>> -John
>>
>>
>> Thanks,
>> -John
>>
>> On Jul 26, 2013, at 12:31 PM, Min Chen <mi...@citrix.com> wrote:
>>
>>> Hi John,
>>>
>>> I saw the blocker defect filed by you regarding this Nomenclature issue(https://issues.apache.org/jira/browse/CLOUDSTACK-3818). Honestly speaking, this does not qualify as a BLOCKER since it is not blocking any functionality. One question I commented on the bug is: do you want to change our UI to call out as "Staging Storage" wherever we have Cache Storage showing up? Or you want us to change all our internal code class and method name (like needCacheStorage, etc) to use a different class/method name? We can do former quite easily, for latter, I don't think that it is that urgent compared to fixing other real functional blockers and criticals for 4.2 release, since that is internal implementation which will be totally shielded from CloudStack user.
>>> Please share your thoughts on this.
>>>
>>> Thanks
>>> -min
>>>
>>> From: Daan Hoogland <da...@gmail.com>
>>> Date: Saturday, July 20, 2013 3:18 AM
>>> To: dev <de...@cloudstack.apache.org>
>>> Cc: Edison Su <Ed...@citrix.com>, Min Chen <mi...@citrix.com>
>>> Subject: Re: [ACS42] NFS Cache Naming
>>>
>>> NFS Staging it was in my recollection.
>>>
>>>
>>> On Fri, Jul 19, 2013 at 10:30 PM, John Burwell <jb...@basho.com> wrote:
>>>> All,
>>>>
>>>> It was my understanding that we had agreed to rename the "NFS Cache" mechanism to reflect that it is not a cache and remove the assumption that it will always be backed by NFS. Is my understanding correct?
>>>>
>>>> Thanks,
>>>> -John
>>>
>>
>
Re: [ACS42] NFS Cache Naming
Posted by Min Chen <mi...@citrix.com>.
John,
Currently we have 3 APIs for previous cache store, they are named as:
createCacheStore
listCacheStores
deleteCacheStore
What are your preferred names for these 3 APIs? Let's get a consensus before I change it to be more effective.
Thanks
-min
From: John Burwell <jb...@basho.com>>
Date: Friday, July 26, 2013 9:43 AM
To: Min Chen <mi...@citrix.com>>
Cc: Daan Hoogland <da...@gmail.com>>, dev <de...@cloudstack.apache.org>>, Edison Su <Ed...@citrix.com>>
Subject: Re: [ACS42] NFS Cache Naming
Min,
That is my recommendation with a task ticket to make the consistent post 4.2.0.
Thanks,
-John
On Jul 26, 2013, at 12:42 PM, Min Chen <mi...@citrix.com>> wrote:
So from your email below, the consensus is to fix user visible elements (UI, API, Configuration, Documentation) in 4.2, I will address that bug based on this understanding.
Thanks for your clarification.
-min
From: John Burwell <jb...@basho.com>>
Date: Friday, July 26, 2013 9:38 AM
To: Min Chen <mi...@citrix.com>>
Cc: Daan Hoogland <da...@gmail.com>>, dev <de...@cloudstack.apache.org>>, Edison Su <Ed...@citrix.com>>
Subject: Re: [ACS42] NFS Cache Naming
Min,
In my opinion, it is a blocker because it is very misleading to operations, and once the name ships in documentation/UI/APIs it will essentially irreversible. Furthermore, as a community, we agreed to make this change in late May/early June. In view, community decisions for a release that are not carried in a release should become a blocker.
I added a comment the following comment to the ticket which, I hope, will answer your question:
Min,
Ideally, both. However, given the short window, the priority is for all user visible elements (e.g. API, UI, configuration files, documentation, etc).
If we do not have time address code, please open a task ticket to refactor the naming internally for post-4.2.0 work.
Thanks,
-John
Thanks,
-John
On Jul 26, 2013, at 12:31 PM, Min Chen <mi...@citrix.com>> wrote:
Hi John,
I saw the blocker defect filed by you regarding this Nomenclature issue(https://issues.apache.org/jira/browse/CLOUDSTACK-3818). Honestly speaking, this does not qualify as a BLOCKER since it is not blocking any functionality. One question I commented on the bug is: do you want to change our UI to call out as "Staging Storage" wherever we have Cache Storage showing up? Or you want us to change all our internal code class and method name (like needCacheStorage, etc) to use a different class/method name? We can do former quite easily, for latter, I don't think that it is that urgent compared to fixing other real functional blockers and criticals for 4.2 release, since that is internal implementation which will be totally shielded from CloudStack user.
Please share your thoughts on this.
Thanks
-min
From: Daan Hoogland <da...@gmail.com>>
Date: Saturday, July 20, 2013 3:18 AM
To: dev <de...@cloudstack.apache.org>>
Cc: Edison Su <Ed...@citrix.com>>, Min Chen <mi...@citrix.com>>
Subject: Re: [ACS42] NFS Cache Naming
NFS Staging it was in my recollection.
On Fri, Jul 19, 2013 at 10:30 PM, John Burwell <jb...@basho.com>> wrote:
All,
It was my understanding that we had agreed to rename the "NFS Cache" mechanism to reflect that it is not a cache and remove the assumption that it will always be backed by NFS. Is my understanding correct?
Thanks,
-John
Re: [ACS42] NFS Cache Naming
Posted by John Burwell <jb...@basho.com>.
Min,
That is my recommendation with a task ticket to make the consistent post 4.2.0.
Thanks,
-John
On Jul 26, 2013, at 12:42 PM, Min Chen <mi...@citrix.com> wrote:
> So from your email below, the consensus is to fix user visible elements (UI, API, Configuration, Documentation) in 4.2, I will address that bug based on this understanding.
>
> Thanks for your clarification.
> -min
>
> From: John Burwell <jb...@basho.com>
> Date: Friday, July 26, 2013 9:38 AM
> To: Min Chen <mi...@citrix.com>
> Cc: Daan Hoogland <da...@gmail.com>, dev <de...@cloudstack.apache.org>, Edison Su <Ed...@citrix.com>
> Subject: Re: [ACS42] NFS Cache Naming
>
> Min,
>
> In my opinion, it is a blocker because it is very misleading to operations, and once the name ships in documentation/UI/APIs it will essentially irreversible. Furthermore, as a community, we agreed to make this change in late May/early June. In view, community decisions for a release that are not carried in a release should become a blocker.
>
> I added a comment the following comment to the ticket which, I hope, will answer your question:
>
>> Min,
>>
>> Ideally, both. However, given the short window, the priority is for all user visible elements (e.g. API, UI, configuration files, documentation, etc).
>>
>> If we do not have time address code, please open a task ticket to refactor the naming internally for post-4.2.0 work.
>>
>> Thanks,
>> -John
>
>
> Thanks,
> -John
>
> On Jul 26, 2013, at 12:31 PM, Min Chen <mi...@citrix.com> wrote:
>
>> Hi John,
>>
>> I saw the blocker defect filed by you regarding this Nomenclature issue(https://issues.apache.org/jira/browse/CLOUDSTACK-3818). Honestly speaking, this does not qualify as a BLOCKER since it is not blocking any functionality. One question I commented on the bug is: do you want to change our UI to call out as "Staging Storage" wherever we have Cache Storage showing up? Or you want us to change all our internal code class and method name (like needCacheStorage, etc) to use a different class/method name? We can do former quite easily, for latter, I don't think that it is that urgent compared to fixing other real functional blockers and criticals for 4.2 release, since that is internal implementation which will be totally shielded from CloudStack user.
>> Please share your thoughts on this.
>>
>> Thanks
>> -min
>>
>> From: Daan Hoogland <da...@gmail.com>
>> Date: Saturday, July 20, 2013 3:18 AM
>> To: dev <de...@cloudstack.apache.org>
>> Cc: Edison Su <Ed...@citrix.com>, Min Chen <mi...@citrix.com>
>> Subject: Re: [ACS42] NFS Cache Naming
>>
>> NFS Staging it was in my recollection.
>>
>>
>> On Fri, Jul 19, 2013 at 10:30 PM, John Burwell <jb...@basho.com> wrote:
>>> All,
>>>
>>> It was my understanding that we had agreed to rename the "NFS Cache" mechanism to reflect that it is not a cache and remove the assumption that it will always be backed by NFS. Is my understanding correct?
>>>
>>> Thanks,
>>> -John
>>
>
Re: [ACS42] NFS Cache Naming
Posted by Min Chen <mi...@citrix.com>.
So from your email below, the consensus is to fix user visible elements (UI, API, Configuration, Documentation) in 4.2, I will address that bug based on this understanding.
Thanks for your clarification.
-min
From: John Burwell <jb...@basho.com>>
Date: Friday, July 26, 2013 9:38 AM
To: Min Chen <mi...@citrix.com>>
Cc: Daan Hoogland <da...@gmail.com>>, dev <de...@cloudstack.apache.org>>, Edison Su <Ed...@citrix.com>>
Subject: Re: [ACS42] NFS Cache Naming
Min,
In my opinion, it is a blocker because it is very misleading to operations, and once the name ships in documentation/UI/APIs it will essentially irreversible. Furthermore, as a community, we agreed to make this change in late May/early June. In view, community decisions for a release that are not carried in a release should become a blocker.
I added a comment the following comment to the ticket which, I hope, will answer your question:
Min,
Ideally, both. However, given the short window, the priority is for all user visible elements (e.g. API, UI, configuration files, documentation, etc).
If we do not have time address code, please open a task ticket to refactor the naming internally for post-4.2.0 work.
Thanks,
-John
Thanks,
-John
On Jul 26, 2013, at 12:31 PM, Min Chen <mi...@citrix.com>> wrote:
Hi John,
I saw the blocker defect filed by you regarding this Nomenclature issue(https://issues.apache.org/jira/browse/CLOUDSTACK-3818). Honestly speaking, this does not qualify as a BLOCKER since it is not blocking any functionality. One question I commented on the bug is: do you want to change our UI to call out as "Staging Storage" wherever we have Cache Storage showing up? Or you want us to change all our internal code class and method name (like needCacheStorage, etc) to use a different class/method name? We can do former quite easily, for latter, I don't think that it is that urgent compared to fixing other real functional blockers and criticals for 4.2 release, since that is internal implementation which will be totally shielded from CloudStack user.
Please share your thoughts on this.
Thanks
-min
From: Daan Hoogland <da...@gmail.com>>
Date: Saturday, July 20, 2013 3:18 AM
To: dev <de...@cloudstack.apache.org>>
Cc: Edison Su <Ed...@citrix.com>>, Min Chen <mi...@citrix.com>>
Subject: Re: [ACS42] NFS Cache Naming
NFS Staging it was in my recollection.
On Fri, Jul 19, 2013 at 10:30 PM, John Burwell <jb...@basho.com>> wrote:
All,
It was my understanding that we had agreed to rename the "NFS Cache" mechanism to reflect that it is not a cache and remove the assumption that it will always be backed by NFS. Is my understanding correct?
Thanks,
-John
Re: [ACS42] NFS Cache Naming
Posted by John Burwell <jb...@basho.com>.
Min,
In my opinion, it is a blocker because it is very misleading to operations, and once the name ships in documentation/UI/APIs it will essentially irreversible. Furthermore, as a community, we agreed to make this change in late May/early June. In view, community decisions for a release that are not carried in a release should become a blocker.
I added a comment the following comment to the ticket which, I hope, will answer your question:
Min,
Ideally, both. However, given the short window, the priority is for all user visible elements (e.g. API, UI, configuration files, documentation, etc).
If we do not have time address code, please open a task ticket to refactor the naming internally for post-4.2.0 work.
Thanks,
-John
Thanks,
-John
On Jul 26, 2013, at 12:31 PM, Min Chen <mi...@citrix.com> wrote:
> Hi John,
>
> I saw the blocker defect filed by you regarding this Nomenclature issue(https://issues.apache.org/jira/browse/CLOUDSTACK-3818). Honestly speaking, this does not qualify as a BLOCKER since it is not blocking any functionality. One question I commented on the bug is: do you want to change our UI to call out as "Staging Storage" wherever we have Cache Storage showing up? Or you want us to change all our internal code class and method name (like needCacheStorage, etc) to use a different class/method name? We can do former quite easily, for latter, I don't think that it is that urgent compared to fixing other real functional blockers and criticals for 4.2 release, since that is internal implementation which will be totally shielded from CloudStack user.
> Please share your thoughts on this.
>
> Thanks
> -min
>
> From: Daan Hoogland <da...@gmail.com>
> Date: Saturday, July 20, 2013 3:18 AM
> To: dev <de...@cloudstack.apache.org>
> Cc: Edison Su <Ed...@citrix.com>, Min Chen <mi...@citrix.com>
> Subject: Re: [ACS42] NFS Cache Naming
>
> NFS Staging it was in my recollection.
>
>
> On Fri, Jul 19, 2013 at 10:30 PM, John Burwell <jb...@basho.com> wrote:
>> All,
>>
>> It was my understanding that we had agreed to rename the "NFS Cache" mechanism to reflect that it is not a cache and remove the assumption that it will always be backed by NFS. Is my understanding correct?
>>
>> Thanks,
>> -John
>
Re: [ACS42] NFS Cache Naming
Posted by Min Chen <mi...@citrix.com>.
Hi John,
I saw the blocker defect filed by you regarding this Nomenclature issue(https://issues.apache.org/jira/browse/CLOUDSTACK-3818). Honestly speaking, this does not qualify as a BLOCKER since it is not blocking any functionality. One question I commented on the bug is: do you want to change our UI to call out as "Staging Storage" wherever we have Cache Storage showing up? Or you want us to change all our internal code class and method name (like needCacheStorage, etc) to use a different class/method name? We can do former quite easily, for latter, I don't think that it is that urgent compared to fixing other real functional blockers and criticals for 4.2 release, since that is internal implementation which will be totally shielded from CloudStack user.
Please share your thoughts on this.
Thanks
-min
From: Daan Hoogland <da...@gmail.com>>
Date: Saturday, July 20, 2013 3:18 AM
To: dev <de...@cloudstack.apache.org>>
Cc: Edison Su <Ed...@citrix.com>>, Min Chen <mi...@citrix.com>>
Subject: Re: [ACS42] NFS Cache Naming
NFS Staging it was in my recollection.
On Fri, Jul 19, 2013 at 10:30 PM, John Burwell <jb...@basho.com>> wrote:
All,
It was my understanding that we had agreed to rename the "NFS Cache" mechanism to reflect that it is not a cache and remove the assumption that it will always be backed by NFS. Is my understanding correct?
Thanks,
-John
Re: [ACS42] NFS Cache Naming
Posted by Daan Hoogland <da...@gmail.com>.
NFS Staging it was in my recollection.
On Fri, Jul 19, 2013 at 10:30 PM, John Burwell <jb...@basho.com> wrote:
> All,
>
> It was my understanding that we had agreed to rename the "NFS Cache"
> mechanism to reflect that it is not a cache and remove the assumption that
> it will always be backed by NFS. Is my understanding correct?
>
> Thanks,
> -John