Quoting [Sylvain Reynaud] (Jun 05 2009):
Andre Merzky a écrit :
Hi again,
Hi again,
Quoting [Sylvain Reynaud] (Jun 05 2009):
- Queue: this attribute makes the job description dependent on the targeted execution site, this information should be put in the URL instead.
Interesting point. The problem I see is that its hard to define a standard way on *how* to encode it in the URL, as each URL component (host, path, query, ...) may already be interpreted by the backend.
For example, a globus job manager URL may well look like
https://some.remote.host:9443/wsrf/services/ManagedExecutableJobService?65e5...
Where would you put the queue?
In JSAGA, such URL is used internally, user gives this URL: wsgram://some.remote.host:9443/Fork
sure, that will mostly work. The point is however, that we can't assure that it breaks for other backends which require a path specification on the URL.
But anyway, I think that the main point is not to know if we should put it in the URL or not, it is rather to know if the queue is part of the job description or part of the targeted resource.
IMHO, the answer is "targeted resource", because if the service discovery extension does not provide this information (either in the URL or in the service_data object), you can not guess it by yourself.
Hi Sylvain, yes, excellent description of the problem: it should be part of the resource specification, not part of the job description. Alas, we don't have a resource description (yet). BTW, the same holds IMHO for CPUArchitecture for example, doesn't it?
If encoding the queue in the URL is not an acceptable solution, then I think the queue should be moved from attributes of job description to arguments of method job_service.create_job.
Thats also an option. What would be the difference however to keeping it in the job description? The info arrives at the same call, once in the description, once separate.
The difference is that other attributes in job description do not depend on a particular execution site or a particular grid. Hence the same job description object could be used to run jobs on different hosts (and even on different grids) if it has no attribute "Queue".
Ideally that may be true, but in practice, CPUArchitecture, OperatingSystem, and others pose similar limitations. Anyway, don't get me wrong: I think I mostly agree with you about the problem statement, and the cause. I am not 100% about the proposed solution, but that may be just me, being hesitant to change (I'm known for that I'm afraid)...
I understand that having only JSDL approved keys in the job description is a clean solution - but that is mostly for the benefit of the SAGA implementors. For the SAGA users, that makes not much of the difference, IMHO.
Since they are not in the JSDL specification, these attributes are likely to be put at stake... Moreover, the SAGA specification says these attributes "might disappear in future versions of the SAGA API".
But I agree, if their usefulness is confirmed, they must be kept.
I think, in the long run, further versions of JSDL, and JSDL extensions, will make our live much easier...
SAGA Name Spaces: ================ * add a flag to disable checking existence of entry in constructor and open methods, because the cost for this check is not negligible with some protocols (then subsequent method calls on this object may throw an IncorrectState exception if the entry does not exist).
Makes sense. We could also overload 'Exclusive', which, at the moment, is only evaluated if 'Create' is specified. It has the same semantic meaning so (inversed): if 'Exclusive' is not specified on 'Create', an existing file is ignored.
Would it make sense to allow Exclusive to be evaluated on all c'tors and open calls?
Any feedback on this one? :-)
Good idea IMHO, but then I think the name of this flag should be changed to one suitable for both use-cases : exclusive creation and no file existence check.
Ah, well, naming - you are opening a bottomless pit! ;-) Any proposal? I throw in 'FailIfExists' ...
I am still not sure about introducing an additional exception here, but that is another issue...
Maybe the right exception to be thrown is AuthenticationFailed. Then its description should be changed to something like this (page 40) :
<< An operation failed because session could not successfully be used for authentication (none of the available contexts could be used, or can not determine which context to use). >>
I think thats an excellent proposal. Best regards, Andre. -- Nothing is ever easy.