[Saga-devel] saga SVN commit 3395: /trunk/saga/impl/engine/

[Livesey, P (Paul)]

Hi,

I'm probably not the best person to answer this but personally I don't mind which way you go.

>From my point of view, each VO has a list of "Group/Role" values that we're interested in that ideally needs
to be kept close to the list of VOs.  That's the only other data that we're really interested in.

Paul.


-----Original Message-----
From: Andre Merzky on behalf of Andre Merzky
Sent: Thu 29/01/2009 15:52
To: Livesey, P (Paul)
Cc: Andre Merzky; Hartmut Kaiser; saga-devel at cct.lsu.edu; Fisher, SM (Steve)
Subject: Re: [Saga-devel] saga SVN commit 3395: /trunk/saga/impl/engine/
 
Hi Paul, 

thanks for the details!  As said, we did not expect a single
cert to be valid in multiple VOs - so that is an oversight
from the standard side I guess.  

I see two options: fix the standard to support VO as vector
attrib (but then we should check carefully what other
attribs need to be vectors, if any -- do you have any input
here?); or live with it as is.

In the latter case, couldn't you create a context for each
VO you find, with otherwise identical attributes?  I do
something like that in the aws_context adaptor, which picks
up several different certificates.

I guess fixing the spec is the 'right thing to do' though.

Cheers, Andre.


Quoting [Livesey, P (Paul)] (Jan 29 2009):
> 
> Hi Andre,
> 
> Our use case for this is as follows, I think!
> 
> The glite proxy certificates we're using may have many VOs and Group/Role entries in them.
> It's reasonably expensive to get at this information and pass it all about.
> What we wanted to be able to do was process the proxy certificate once and store
> the results somewhere easily accessible that could potentially be shared across multiple
> glite adaptors.
> 
> We can always store the location of the proxy certificate in the context and
> process it when needed so it's not a huge problem.
> 
> Paul.
> 
> 
> -----Original Message-----
> From: Andre Merzky on behalf of 'Andre Merzky'
> Sent: Thu 29/01/2009 14:38
> To: Hartmut Kaiser
> Cc: 'Andre Merzky'; saga-devel at cct.lsu.edu; Livesey, P (Paul)
> Subject: Re: [Saga-devel] saga SVN commit 3395: /trunk/saga/impl/engine/
>  
> Quoting [Hartmut Kaiser] (Jan 28 2009):
> > > 
> > > Sorry for not looking at the diff - but is that on API or on
> > > CPI level?  On API level, context should have
> > > non-extensible attributes, and there are no vector
> > > attributes defined...
> > 
> > That's on CPI level but has impact on the API as well. I'm fully aware of
> > the spec's limitations here, but I implemented the vector
> > attributes/extensible attributes for contexts based on Paul's request. He
> > seems to have a use case for that.
> > 
> > Paul/Andre, could you please discuss this?
> 
> Hi Paul, 
> 
> so what is the specific use case for this?  Originally, a
> saga::context instance is supposed to represent one security
> token (proxy, certificate, or whatever).  Usually, one such
> token only holds for one VO, IIUC.  In fact, IMHO a VO is at
> least partially defined by sharing these types of security
> tokens.
> 
> If tokens are valid beyond a specific VO (for example if a
> TeraGrid globus cert is also valid for the NGS in the UK),
> then either the backend (or the adaptor) should simply
> accept the TG context, or the end user would create two
> contexts pointing to the same cert, but specifying different
> VO's.  Or letting the VO unset of course.
> 
> Does that scheme break for you?  If so, how?
> 
> Thanks, Andre.
-- 
Nothing is ever easy.

-- 
Scanned by iCritical.