[glue-wg] Glue 2.1 draft new version (0.5) - little modification

Alessandro Paolini alessandro.paolini at egi.eu
Thu Aug 24 10:28:10 EDT 2017


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/glue-wg/attachments/20170824/d11601c1/attachment.html>


More information about the glue-wg mailing list