[SAGA-RG] Suggested errata to the SD spec

Hartmut Kaiser hkaiser at cct.lsu.edu
Wed Apr 15 13:15:14 CDT 2009 

> Sorry, Steve, I feel embarassed, but I don't get your point
> :-( Please bear with me, and allow me to draw some use cases
> in pseudo code.
> 
> 1: with URL specified:
> 
>   When you do
> 
>     discoverer d ("glite://cern.ch");
>     list = d.discover (...);
> 
>   and you have 5 adaptors (made up list)
> 
>     glite
>     mds
>     local
>     unicore
>     condor
> 
>   then you get a valid response from the glite adaptor.  You
>   get no errors from the other adaptors, and no time overhead
>   to speak off.
> 
> 
> 2: w/o URL specified
> 
>   When you do
> 
>     discoverer d ();
>     list = d.discover (...);
> 
>   and you have 5 adaptors (made up list)
> 
>     glite
>     mds
>     local
>     unicore
>     condor
> 
>   then you get a valid response from the *each* adaptor, and
>   the results are collated in the list.  The endpoints to be
>   contacted by each adaptor are configured on compile time,
>   or via a config file, or environment.  That is copletely
>   implementation specific.
> 
> 
> I take it is case 1 you worry about, right?  I don't see yet
> why - where do you think you would get confusing errors, or
> where do you think we get overhead?
> 
> About overhead: invoking adaptors to check a URL costs next
> to nothing if compared to any remote call.

One thing we still didn't implement in the engine is the possibility to
attach (query) multiple adaptors for the very same API call. We already
discussed the necessity of such a thing but deferred its implementation. The
candidate for this type of API calls we got inspired from is the
sd::discoverer::discover :-P. But there might be more.

I'm not sure, whether this is what Steve complains about, so please ignore
this if not.

Regards Hartmut

> 
> Thanks, Andre.
> 
> 
> Quoting [Steve Fisher] (Apr 15 2009):
> >
> > Andre,
> >
> > I agree that it will work fine with exactly one adapter. However if
> he
> > tries on a system with multiple adapters then it will be very
> > inefficient and he will get lets of odd errors just because there are
> > some adapters that he does not know about. I assume that this
> software
> > will be installed by sysadmins on behalf of the users - and so on a
> > multi-user machine there will normally be many adapters.
> >
> > If you think that this is "reasonable" behaviour then no change is
> needed.
> >
> > Steve
> >
> > 2009/4/15 Andre Merzky <andre at merzky.net>:
> > > Quoting [Steve Fisher] (Apr 15 2009):
> > >>
> > >> 2009/4/15 Andre Merzky <andre at merzky.net>:
> > >> > Hi Steve,
> > >> >
> > >> > Quoting [Steve Fisher] (Apr 15 2009):
> > >> >>
> > >> >> Hi,
> > >> >>
> > >> >> We would like to get rid of the URL passed into the discoverer
> > >> >> constructor. Its comment is:
> > >> >>
> > >> >> "the url specified as in input parameter is to assist the
> > >> >> implementation to locate the underlying information system such
> that
> > >> >> it can be queried"
> > >> >>
> > >> >> The problem we have is that this does not work with an adapter
> based
> > >> >> implementation as the URL is normally specific to the adapter.
> > >> >
> > >> > I'm sorry, you lost me: why is that not working?  The
> > >> > implementation should be able to forward the URL to the
> > >> > adaptor, where it is needed?
> > >>
> > >> The implementation must pass it to all adapters - but it will only
> > >> make sense to one of them. For gLite it would point to some BDII
> > >> server which provides information for gLite. No other adapter is
> > >> likely to be able to make sense of this.
> > >>
> > >> The only real benefit of the engine with multiple adapters is if
> > >> multiple adapters can be used in one call.
> > >>
> > >> I think the Job Service will have much the same problem as
> typically
> > >> only one adapter can actually be expected to respond sensibly and
> > >> accept the job it is given. Even if you have used Service
> Discovery to
> > >> get the URL of the Job Service to use the saga engine will still
> have
> > >> to cycle through making calls to all the adaptors ahead of the one
> > >> that is going to work for you. So in this case you really want to
> be
> > >> able to dynamically influence the sequence of adaptors to avoid a
> load
> > >> of wasted network calls - and timeout delays ...
> > >
> > > In that case, don't use an URL for the API call.  Then you
> > > can fall back to the configure file option you mentioned.
> > >
> > > The URL is supposed to be specified if the end user expects
> > > exactly *one* endpoint to be used.  For example, I would
> > > specify a gram URL if I know I'll only submit jobs to that
> > > GRAM instance.  That additionally saves the implementation
> > > the hazzle to try other adaptors, wnd thus improves
> > > performance.
> > >
> > > I still don't see where you think it is broken, as the URL
> > > is optional.  Why would removing the URL arg any difference
> > > compared to just leaving it out in the API call?
> > >
> > > Thanks, Andre.
> > >
> > >
> > >>
> > >> Steve
> > >>
> > >>
> > >> >
> > >> >
> > >> >> This information can be passed to the adapter using a
> > >> >> configuration file or an environment variable according to
> > >> >> the style adpopted by the adaper writer.
> > >> >
> > >> > That is an orthogonal issue IMHO.
> > >> >
> > >> > I would like to compare that to the job::service, where we
> > >> > give a contact URL for the job submission endpoint.  That
> > >> > URL is adaptor specific, e.g. it could be
> > >> > 'gram://remote.globus.host:123/'.  That URL would then be
> > >> > forwarded to the adaptors.  Only the globus adaptor would
> > >> > accept it, and act on job submission requests.
> > >> >
> > >> > OTOH, if the URL is not specified (it is optional in te
> > >> > API), then a default URL from the adaptor configuration
> > >> > files is used.  That could also be an env variable, as you
> > >> > state above.
> > >> >
> > >> > What is the problem with that scheme?  Seems to work for
> > >> > job::service and other classes - why not for the service
> > >> > discoverer?
> > >> >
> > >> > Thanks, Andre.
> > >> >
> > >> >
> > >> >
> > >> >> The constructor then just has the session handle
> > >> >>
> > >> >> The other change is to make the attribute names consistent with
> the
> > >> >> rest of SAGA - i.e. CamelCased
> > >> >>
> > >> >> Steve
> > >> > --
> > >> > Nothing is ever easy.
> > >> >
> > >
> > >
> > >
> > > --
> > > Nothing is ever easy.
> > >
> 
> 
> 
> --
> Nothing is ever easy.
> --
>   saga-rg mailing list
>   saga-rg at ogf.org
>   http://www.ogf.org/mailman/listinfo/saga-rg

More information about the saga-rg mailing list