[glue-wg] My Full Support for the concept of Name Space within GLUE

[owen.synge at desy.de]

From: Owen Synge <owen at alice-dsl.de>
To: "owen.synge at desy.de" <owen.synge at desy.de>
Subject: Re: [glue-wg] Comparison with CIM
Date: Sat, 3 May 2008 00:06:39 +0200
X-Mailer: Sylpheed version 2.3.0beta5 (GTK+ 2.8.20; i486-pc-linux-gnu)

On Thu, 1 May 2008 11:52:23 +0100
"Burke, S (Stephen)" <S.Burke at rl.ac.uk> wrote:

> it seems that the lack of convergence in authz models has
> pushed LCG into asking to have two separate kinds of authz (on
> namespaces and space tokens) and that does need to be considered for
> GLUE because it would affect the model, e.g. Flavia's proposal to have a
> new object for namespaces.

Dear Steven,

I would support a name space entity in GLUE. Please remember if Paul
represents dCache not I.

Provided its little more than an entity to provide scoping (VO) and
features (Authorisation model, implementation, version number) rather
than the content of the name space I would support Flavia's suggestion.

Certainly authorisation model would be best expressed in a name space.
If the name space content where to be duplicated in GLUE I would
strongly oppose it. 

I believe that a name space maybe independent of a storage element. But
that storage elements may reference them which is the case within a wLCG
context.

This would be useful as for example FERMI have many logically separate
name spaces for a single dCache instance, while NorduGrid have many
Storage elements with a single namespace.

I feel that a name space is a useful discoverable service that wLCG
assumes is currently tightly coupled to the storage element, but its
equally applicable to a replica catalogue.

I would also hope that we would also have one name space for a
logical name space and them all associated with a Parent name space,
similar to a UNIX mount since we have converged on a hierarchical
model. 

If/when the name space directories support different collections of VO's
then I suggest they should be separate instances.

eg 

/castor/cern.ch
/castor/cern.ch/cms

should be two name spaces to my mind one for all supported VO's and one
for CMS in this example.

I also see one or more synchronisation services associated to a name
space for synchronisation between catalogues and storage elements. 

Regards

Owen Synge