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

Sylvain Reynaud Sylvain.Reynaud at in2p3.fr
Wed Oct 22 03:21:11 CDT 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.

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.

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



More information about the saga-rg mailing list