[SAGA-RG] SAGA SD Final?? Version

[Andre Merzky]

Hi Steve, 

here are my belated comments:

Quoting [Fisher, SM (Steve)] (Jan 02 2008):
> From: "Fisher, SM (Steve)" <S.M.Fisher at rl.ac.uk>
> To: SAGA RG <saga-rg at ogf.org>
> Subject: [SAGA-RG] SAGA SD Final?? Version
> 
> Hi,
> 
> We have made the following changes to the Service Discovery spec:
> 
> #1  Section 2.1.1: now includes reference to GLUE

perfect.


> #2  Should the default VOs be chosen from the session object?
> 
> As we are not able to come up with an intuitive syntax that allows the
> user to be able to request specific VOs or to take one from the
> security context we prefer to leave this as it is. 

I was somewhat unclear here I guess, as you would need no
additional syntax, but only additional semantics:

  // pseudocode!

  saga::context c ('X509');


  c.set_attribute ('UserVO', 'O=dutchgrid');

  // create a saga session which uses that context
  saga::session s;
  s.add_context (c);

  // create a service discoverer in that session
  saga::service::discoverer sd (s);

  // when searching for services, and when no VO filter is
  // specified, we imply an VO filter from the session
  // contexts
  sd.discover ("Type = 'Broker' AND name = 'CERN-PROD-rb'",
               "",
               "RunningJobs > 10");

  // this is thus actually the same as:
  sd.discover ("Type = 'Broker' AND name = 'CERN-PROD-rb'",
               "VO IN ('O=Dutchgrid')",
               "RunningJobs > 10");

The syntax is the same as before, but semantically, the
empty VO filter is interpreted differently.

Does that make sense?  It would free the user from the need
to explicitely filter for VOs.  In fact, as the session is
defined to pick up default credentials, the user would not
need to know anything about VOs at all, and still receive
only services which are actually usable for his credentials.
That should nicely fit to the 'S' in SAGA ;-)

OTOH, one can revert to the old semantics with the VO filter
'VO=*' (I guess?  Or is is "VO LIKE '%'"?).


> #3  When there is Authz failure, should list_services 
>     throw 'NotEnoughPermission' exception?
> 
> We have added the AuthorizationFailed exception
> 
> (Incidentally I don't like the distinction between PermissionDenied and
> AuthorizationFailed in the core specification. I see no adequate
> justification for it - Steve)

The spec says: 

  'The differences between AuthorizationFailed and
   PermissionDenied are, admit- tedly, subtle. Our intention
   for introducing both exceptions was to allow to dis-
   tinguish between administrative authorization failures (on
   VO and DN level), and backend related authorization
   failures (which can often be resolved on user level).'

Yes, we know its a weak distinction, and slightly arbitrary
- OTOH, it may provide a help to the end user, and give him
a hint when to contact an admin.  That is an often occuring
problem in all projects I was involved in, that users get
all types of security errors, and never know when they can
fix it (or not).


> #4  To mention compliance to upcoming GLUE stds. (GLUE 2?).
>     Whether GLUE upgrades affect the document? if so, 
>     appropriate mentioning required. (comments: similar to 
>     SAGA-core spec depending on JSDL)
> 
> A footnote has been added
> 
> The examples have also been updated to correspond precisely to our
> implementation.
> 
> Note that we do now have a complete C++ implementation with gLite
> adapaters. The main code will be checked in as soon as Paventhan has
> write access to the repositoy and the adapter code will go into the
> gLite repository.
> 
> We would like to see the document go to the OGF editor now unless
> somebody sees a problem. The .dvi file is attached.

I have a couple of minor suggestions for the text, mostly
clarifying sentences I had difficulties to parse.  Do you
want me to send it by mail, or would it be ok to change in
CVS directly?

Cheers, Andre.


> Steve and Paventhan
-- 
No trees were destroyed in the sending of this message, however,
a significant number of electrons were terribly inconvenienced.