[SAGA-RG] Suggested errata to the SD spec

[Andre Merzky]

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.

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.