[SAGA-RG] Suggested errata to the SD spec

[Steve Fisher]

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.
>