2008/10/22 Andre Merzky <andre@merzky.net>:
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.
This is certainly a very valid question. It was included in my original design because I was following some of the notions of the current gLite service discovery API (though it is not much used except internally by data management).
+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.
This requirement is already satisfied because if you omit the "VO-filter" the information is taken from your context. The implementation of the API could select using any group or role information without it being visible in the interface
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.
I think the main question is whether or not we should allow selection on authz info and whether or not we should even allow this information to be queried on a returned service. I can only think of 2 reasons to keep it. The first is to make the API useful to someone without a security context and the second is for an application wanting to collect information and make it available on a web page - i.e. republishing the information. Both of these are more relevant to other middleware components than to end users. I will ask a few gLite people to get their opinion. What do you think?
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_rest...), 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@gmail.com <mailto:Dr.S.M.Fisher@gmail.com>> ------------------------------------------------------------------------
-- saga-rg mailing list saga-rg@ogf.org http://www.ogf.org/mailman/listinfo/saga-rg -- Nothing is ever easy.
-- Steve Please note my new e-mail: <Dr.S.M.Fisher@gmail.com>