[SAGA-RG] Context attributes

[Andre Merzky]

Quoting [Steve Fisher] (Feb 06 2009):
> 
> 2009/2/6 Andre Merzky <andre at merzky.net>:
> > Hi Steve, Paul,
> >
> > the set of context attributes is supposed to allow the user
> > to point to a specific security token, in a wide set of
> > environments.  You are right: apart from 'Type', different
> > grid environments will require different attributes to be
> > set.  For example, a MyProxy context would probably specify
> > 'Server', 'UserID' and 'UserPass', while a X509 proxy
> > context would point the 'UserProxy' attribute to the proxie's
> > location in the file system.
> >
> > We hope that the set of attributes cover all currently used
> > Grid middlewares (we had the OGF security area check the
> > attributes for completeness).  If not, that needs fixing.
> 
> In that case the list will just get longer and longer. I was simply
> suggesting that it would be better to only have the "Type" and then
> allowing other attributes to be specified by the user to match the
> implementation he plans to use. If the user explicitly creates a gLite
> context there is no point in setting more than the location of his
> proxy. At the moment he could try setting other attributes - expecting
> them to do something useful - but the implementation will ignore them
> or it could report an error if useless attributes are set.

You are right: the implementation should document what
attributes it supports.  However, a completely free
attribute list may lead to glite using the 'Server'
attribute, MyProxy using 'ServerName', and OMII using
'ServerContact' - a predefined list of supported attributes
avoids that.  It is a tradeoff though, I certainly agree
that other solutions are possible.


> > It is a different story altogether on implementation level
> > though: a context representation within the SAGA
> > implementation may well keep additional attributes, like
> > (for the examples above) the MyProxy server version, or the
> > X509 proxy file checksum.  That might be useful information
> > for the implementation to keep, and to pass around with the
> > context - but these attributes do not need exposure on API
> > level
> 
> > (that is why the context attributes are not > extensible).
> 
> Here I think  you are confusing the API and the implementation. The
> attributes can be extensible - but should not be used by the
> implementation to cache information. If the implementation changes a
> context created by the user (other than the default one) such that the
> user can see that it has been changed - then that implementation is
> broken.

Why?  If I point to a myproxy credential, and the
implementation is refreshing that credential beyond its
default lifetime w/o notifying the user, I don't think the
implementation is broken.

Again: saga::context instance is not supposed to allow the
user to create a credential on API level, or to manage it,
etc - it is solely supposed to _point_ to an existing
credential, and to deliver additional information about it,
if available (such as lifetime).

So, there is no reason not to allow the implementation to
attach additional information, or state attributes, or
whatever to the context internally.  In fact, the
implementation may need to do credential management - and
these actions are not expressed at API level at all.


> > I think the latter is what causes confusion for Paul in the
> > implementation (will send a separate mail on that on the
> > devel list).
> 
> Yes I think that Paul was wrong to try to set the VO in the context as
> all the information is defined in the proxy. In fact what he needs to
> store is all the information unpacked from the proxy which for a VOMS
> proxy is more complex than can be represented easily by attributes -
> even if multi-valued. This should be a private structure and not
> visible to the user via the API. 

Agree.

Best, Andre.


> However I am tying to keep my nose out of the C++
> implementation.
> 
> Steve



-- 
Nothing is ever easy.