[SAGA-RG] One final thing to agree upon for SD

[Andre Merzky]

Quoting [Sylvain Reynaud] (Oct 22 2008):
> 
> Hi,
> 
> Why would a SAGA user want to discover services not available to his VO, 
> if he can not use any of the SAGA-core object with these services? IMHO, 
> enabling such use-case is fine, but a SAGA extension should first 
> concentrate on enhancing the use of SAGA-core objects.

+1

I also think that the results of the discover() call should,
first of all, be usable within a specific saga session.  As
limited as a saga session object might be - discovering
services which do not (easily) map to a session context will
not be very useful to a SAGA programmer, IMHO.

I understand that the SAGA notion of VOs and of
authorization roles etc. does not map 1:1 to Glue's notion,
but IMHO, a best effort should be made to align the SD
package with SAGA semantics, as that is the context where it
will be used.


> Nevertheless, adding non-specified key-value pairs in ?vo_filter? is 
> suitable for me, provided ?vo_filter' be renamed to 'authz_filter'. In 
> doing so, we also keep the possibility to add them as full SD attributes 
> in future versions of the specification as you suggest.

I think that this would make sense once we expand a saga
session, or a saga security context, with similar
attributes.

Cheers, Andre.


> Sylvain
> 
> 
> Steve Fisher a écrit :
> > Hi,
> >
> > I have contacted those who made comments on the SD spec. They were 
> > happy with the proposals agreed upon in Singapore with the exception 
> > of the vo-filter. I thought it was worth bringing this point to the 
> > list for people to think about. Once this is fixed I will edit the 
> > document as agreed.
> >
> > In the main spec the context has an attribute:
> >
> > ! // name: UserVO
> > ! // desc: the VO the context belongs to
> > ! // mode: ReadWrite
> > ! // type: String
> > ! // value: -
> > ! // note: - a typical example for a globus type context
> > ! // would be "O=dutchgrid".
> >
> > Here it is quite reasonable to call it UserVO as it is in the session 
> > context, however for service discovery as the API allows you to find 
> > out about services not available to your VO then UserVO is not the 
> > most natural name and I prefer to leave it as VO (contrary to what I 
> > agreed in Singapore).
> >
> > We also need to be mappable on to GLUE. The GLUE 2.0 document says:
> >
> > In the GLUE Information Model, the Virtual Organization can be 
> > realized by using the concept of UserDomain. If the VO has an internal 
> > structure, this can be represented by using different domains related 
> > to each other. A Virtual Organization (VO) comprises a set of 
> > individuals and/or institutions having direct access to computers, 
> > software, data, and other resources for collaborative problem-solving 
> > or other purposes. Resources utilized by a VO are expected to be 
> > accessible via network endpoints and constrained by defining 
> > utilization targets called shares. The VO can exhibit the internal 
> > structure in terms of groups of individuals, each of them being a 
> > UserDomain. UserDomains can be hierarchically structured. This 
> > structure can be represented via the "participates in" association.
> >
> > Sylvain Reynaud has said:
> >
> > I agree for equivalence between VO and group, but I still think that
> > filtering by group (or VO) is just an example of authorization
> > filtering. Indeed, authorization does not always only depend on group
> > (or VO) membership, even for grid deployments. For example,
> > authorization may also depend on role (e.g. in LCG, access to tier 1
> > sites should be restricted to role "production" instead of the entire
> > VO. See
> > http://goc.grid.sinica.edu.tw/gocwiki/How_to_publish_queues_with_access_restricted_to_a_FQAN),
> > or it may depend only on UserID (e.g. Globus gridmap file). Then, how
> > could we filter the services that are really accessible to the user?
> > Moreover, I think that infrastructures that do not want to make efforts
> > to match the SAGA Service Discovery specification should also be
> > accessible through this API.
> >
> > However I think that going this way leads to an API that can no longer 
> > be considered to be simple. One can of course use the key value pairs 
> > to show groups and roles and any other authz information if it is 
> > wished - so I propose to leave it as it is with just VO. If it turns 
> > out that groups and roles really turn out to be useful as key values 
> > then we can add them in later as full SD attributes - but it is more 
> > troublesome to remove them later.
> >
> > Comments please.
> >
> > Steve
> >
> >
> >
> > -- 
> > Steve
> >
> > Please note my new e-mail: <Dr.S.M.Fisher at gmail.com 
> > <mailto:Dr.S.M.Fisher at gmail.com>>
> > ------------------------------------------------------------------------
> >
> > --
> >   saga-rg mailing list
> >   saga-rg at ogf.org
> >   http://www.ogf.org/mailman/listinfo/saga-rg
-- 
Nothing is ever easy.