Henry, if you insist on thinking that all possible functionality that is
not explicitly excluded by rules that you know about MUST be provided,
you will go mad. But since you seem to thrive on this here are some more
comments,
John
> -----Original Message-----
> From: Testbed Support for GridPP member institutes
> [mailto:[log in to unmask]] On Behalf Of Henry Nebrensky
> Sent: 06 October 2005 23:02
> To: [log in to unmask]
> Subject: Storage Types (was Re: [TB-SUPPORT] Reminder of the
> next UKI meeting)
>
> On Thu, 6 Oct 2005, Gordon, JC (John) wrote:
> >
> > My point is that this needs to be a wider discussion. If
> LT2 ends up
> > offering a service level that no-one wants it is a waste of many
> > things including the discussion. We need to match experiment
> > requirements with service provision. One might think this
> would have
> > been done pre-MoU but obviously not down to this level.
>
> I think the service we provide does generally match what
> experiments require from a Tier*2*
That's a contentious statement since
a) experiments want different things from a Tier2
b) I don't believe they have fully expressed what they want.
>
> > I think you are reading too much into 'permanent'. You can always
> > close down or rename an SE but you have to do it together
> with the VO.
> > For the reasons you mention, they have to move or
> rename/recatalogue data.
>
> No, because anyone can globus-url-copy a file into an SE and
> store the TURL in a catalog. It might be an LCG catalog or
> the VO's catalog, or it could be their own in an Excel
> spreadsheet. Or a Post-It(TM) note.
> So you'd have to trawl years' worth of logs and contact each
> individual uploader:(
No! Not ANYONE. Your authorisation should only allow individuals access
based on their membership of a VO. Thus any use they make or files they
create are the business of the VO - see the AUP. If you tell a VO to
remove their files then they have to contact all their members. More
likely they will only maintain catalogues belonging to the VO, not the
sum of all private ones belonging to members.
I am sure your university library allows itself to scrap books and
remove them from its catalogue even though you might have your own
private list of their books that you have previously referenced.
>
> The point that in principle classic SEs would need to be
> maintained indefinitely has certainly been made in ROLLOUT
> (somewhere close to "why do all these Tier2 sites bother with
> an SE, anyway").
>
> (In practice I think we're saved by so far having few
> end-users doing strange and random things.)
If you pay attention to everyone on ROLLOUT or expect to meet all
requirements of strange and random end-users - see my first sentence:-)
>
>
> Separately, for an SRM "volatile" etc. refers to the attributes of an
> *individual file*. I think using the same vocabulary in things like
> GlueSAType and GlueSAPolicyFileLifeTime which apply to entire storage
> systems is probably a bad idea.
I think you will find that an SRM puts volatile files into volatile
storage space, etc, and it is these storage areas that the Glue Schema
describes. I cannot find anything that states this in a spec but I
remember the use cases from the designing. There is a possibility that
the specs of SRM and Glue have diverged but they are supposed have the
same meanings.
John
|