October 2008 - saga-rg - lists.ogf.org

One final thing to agree upon for SD
by Steve Fisher 19 Nov '08

19 Nov '08

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_res… ), 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(a)gmail.com>

4 12

Cloning and object ids
by Malcolm Illingworth 16 Oct '08

16 Oct '08

Hi, A quick question about cloning and deep copy. If I clone an object, is the saga object identifier supposed to get set to the value from the original object, or get a new value assigned? Thanks, Malcolm. ---------------------------------------------------- |epcc| - Malcolm Illingworth EPCC, University of Edinburgh James Clerk Maxwell Building Mayfield Road E-mail: malcolm(a)epcc.ed.ac.uk Edinburgh EH9 3JZ Phone: + 44 (0) 131 651 3388 United Kingdom Fax: + 44 (0) 131 650 6555 -------------------------------------------------------------

2 1

Re: [SAGA-RG] usage of SAGA_LOCATION
by Mathijs den Burger 15 Oct '08

15 Oct '08

On Wed, 2008-10-15 at 15:10 +0200, PFA van Zoolingen wrote: > > In the latest release CCT's SAGA C++ implementation doesn't require a set > > SAGA_LOCATION environment variable anymore (at least as long as the > > installation has not been moved from the --prefix directory it was > > configured and built with). If no $SAGA_LOCATION is set it internally > > defaults to the directory used during ./configure --prefix=... This doesn't > > free you from the need to properly set your LD_LIBRARY_PATH, but that's > > another issue, I guess. The makefiles in LSU's SAGA C++ implementation (e.g. $SAGA_LOCATION/share/saga/make/saga.application.mk) still need either SAGA_ROOT or SAGA_LOCATION to be set. A user that writes a SAGA app using an existing SAGA C++ installation therefore still needs to set SAGA_LOCATION, otherwise he cannot include saga.application.mk in the makefile of his own application. It's not clear to me whether that's a bug or not, but it seems to conflict with the quoted statement. -Mathijs

3 2

Re: [SAGA-RG] usage of SAGA_LOCATION
by PFA van Zoolingen 15 Oct '08

15 Oct '08

All, > In the latest release CCT's SAGA C++ implementation doesn't require a set > SAGA_LOCATION environment variable anymore (at least as long as the > installation has not been moved from the --prefix directory it was > configured and built with). If no $SAGA_LOCATION is set it internally > defaults to the directory used during ./configure --prefix=... This doesn't > free you from the need to properly set your LD_LIBRARY_PATH, but that's > another issue, I guess. In my case, I don't have root access to my machine and can only access my home-dir. So installing in /usr/local/ is not really an option, and I need the $SAGA_LOCATION set. If I could install it in /usr/local/ and also have the java implementation installed, I still have to set $SAGA_LOCATION to the java implementation. Does this effect the C++ implementation since $SAGA_LOCATION is set, and it overrides internal C++ default? Paul.

2 1

usage of SAGA_LOCATION
by Mathijs den Burger 15 Oct '08

15 Oct '08

Hi all, Both the C++ implementation and the Java implementation of SAGA use the environment variable SAGA_LOCATION to point to the location of the SAGA installation. Right now, it is therefore impossible to use both the C++ and Java SAGA implementation simultaneously without changing SAGA_LOCATION all the time. Even worse, future SAGA implementations may also reuse SAGA_LOCATION. It seems desirable to avoid such clashes between multiple SAGA installations in general. What would be the best generic way to accomplish that? Should the SAGA spec define a global environment variable namespace (e.g. LSU_C++_SAGA_LOCATION, VU_JAVA_SAGA_LOCATION)? And are such environment variables really needed in all implementations in the first place? regards, Mathijs

3 2