[glue-wg] naming the new StorageShare attribute requested by ATLAS

[Alessandro Paolini]

Hi Jens, all

coming back to this topic:

 add a StorageShare attribute that describes the number of
        files stored in this StorageShare.  This should
        be optional (mult: 0..1).

Unfortunately the original email by Paul got lost, and I don't know if
there was some discussion as well at that time, before you remind us this
topic.

I would like just to discuss the name of this new attribute: something like
StorageShareFiles or StorageShareTotalFiles ?

let me know,
alessandro

On 24 August 2017 at 16:28, Alessandro Paolini <alessandro.paolini at egi.eu>
wrote:

> Hi Jens,
>
> sorry for not replying before: I've just noticed that your message (and
> the consequent reply by Stephen) finished in the spam folder...
>
> Regarding the P1, I will correct the document, thank you for spotting this
> (I'm being in vacation since tomorrow till Sep 12th, so in the next two
> weeks i'm not being able to participate to the discussion).
>
> Regarding P2, P3, and P4 it is not completely clear to me the need, maybe
> because I look at the GLUESchema as operator/administrator rather then
> user, and I don't know well the needs of the experiments.
>
> cheers,
> Alessandro
>
> On 23 August 2017 at 16:45, <stephen.burke at stfc.ac.uk> wrote:
>
>> glue-wg [mailto:glue-wg-bounces at ogf.org] On Behalf Of Jensen,
>> > Jens (STFC,RAL,SC) said:
>> > One thing I did not see in this document - but had expected? - was to
>> > address Paul's suggestions from November last year. See attached.
>>
>> We didn't discuss this, but my comments would be:
>>
>> P1: seems uncontroversial.
>>
>> P2: The semantics for multiple paths would need to be clear - in the past
>> it was used as a default path on which to write files, if you have more
>> than one it wouldn't be obvious. A more backward compatible approach would
>> be to add a new multivalued attribute for additional paths, then it's clear
>> that the existing one should be the default.
>>
>> P3: The reason for having a separate Capacity object was that there are
>> potentially many different semantics for what the attributes can refer to.
>> Putting the attributes back in the main object would need both a clear
>> definition for which precise semantics are intended, and a case for why
>> those particular semantics are universally the most important ones.
>> Personally I don't think it's a useful idea given that the information is
>> already available from the existing object.
>>
>> P4: Seems like a strange idea to me. StorageShareCapacity is logically a
>> part of the StorageShare object, hence the name and indeed the proposal in
>> P3. If a similar object is wanted for Datastore then it should be a new
>> object with a new name. In principle it's possible that one Share could be
>> spread across multiple Datastores so there's no simple relation between
>> them.
>>
>> Stephen
>>
>>
>>
>> _______________________________________________
>> glue-wg mailing list
>> glue-wg at ogf.org
>> https://www.ogf.org/mailman/listinfo/glue-wg
>>
>
>
>
> --
> Dr. Alessandro Paolini
> Operations Officer - EGI Foundation
> Science Park 140
> 1098 XG Amsterdam
> The Netherlands
> skype: alessandro.paolini.egi
> *********************************
> "I believe in the power of laughter and tears"
>     "as an antidote to hatred and terror"
>           "A day without laughter"
>              "is a wasted day" >>> Charlie Chaplin
>



-- 
Dr. Alessandro Paolini
Operations Officer - EGI Foundation
Science Park 140
1098 XG Amsterdam
The Netherlands
skype: alessandro.paolini.egi
*********************************
"I believe in the power of laughter and tears"
    "as an antidote to hatred and terror"
          "A day without laughter"
             "is a wasted day" >>> Charlie Chaplin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/glue-wg/attachments/20170913/9d3743d2/attachment-0001.html>