Quick check before a job is sent

[sina-masoud-ansari]

When a user submits a job, a quick check may be good to see that required values are set.

gricli> set version null gricli> set group null gricli> submit "sleep 100" job property is not validsubmissionLocation: Submissionlocation default:gram5.ceres.auckland.ac.nz not available for this kind of job (using VO: null)

instead we could have:

The global variable 'group' must be set. Use 'print groups' to see available groups.

The global variable 'version' must be set. Use 'help version' for more information.

Something along these lines is preferable to the error. Unless we can change the exception handling, but this may be a quick easy fix for these sorts of problems. Also the current state may be sufficient once job properties match their 'global' names as in #104. Just wondering how we can make this a bit friendlier / more informative ot the use. Thoughts?

[ndjones]

Agreed Sina, this is a presentation issue, and we need to aim for consistency and ease of intuitive understanding, along with some guidance, as you suggest.

Would it be best to have a presentation mapping, with a set of strings in an easy to edit resources file, that are mapped to specific known exceptions, so that we can present friendlier user instructions and guidance?

[makkus]

Thing is, version (and also group, in a way) don't need to be explicitly set. If no version is set, "any" will be used.

If no group is set "/nz" is used. Now, "/nz" is not mapped to anything so that it will result in error. For that, I'd suggest to auto-set it to the last vo a job was submitted as, from the last session. Swing client remember that, for example.

[ndjones]

If no group is set "/nz" is used. Now, "/nz" is not mapped to anything so that it will result in error. For that,

/nz was going to have a default level of resource as demo, or was that /nz/demo? If /nz has nothing, and no prior job has been submitted, then perhaps we should catch that case, as Sina suggests, and provide guidance. It's a good opportunity to provide some guidance that essential leads through trial and error to the user learning about submitting jobs, and does so successfully.

I'd suggest to auto-set it to the last vo a job was submitted as, from the last session. Swing client remember that, for example.

Do we have any ability to "save globals", set persistglobalsbetweensessions = true, or some other mechanism to support this? It's not just VO...

[makkus]

On 27/07/11 09:16, ndjones wrote:

/nz was going to have a default level of resource as demo, or was that /nz/demo? If /nz has nothing, and no prior job has been submitted, then perhaps we should catch that case, as Sina suggests, and provide guidance. It's a good opportunity to provide some guidance that essential leads through trial and error to the user learning about submitting jobs, and does so successfully. Ok, that would make sense. Do we have any ability to "save globals", set persistglobalsbetweensessions = true, or some other mechanism to support this? It's not just VO...

Yes, question is whether we want to do that on a per client-host basis (i.e. it is stored in a config file on the machine where gricli is installed) or "backend-wide" so each gricli-client that connects to that backend gets those.

We can do both, I'd opt for the former. Seems cleaner to me, but doing it backend-wide wouldn't bother me either...

[ndjones]

Do we have any ability to "save globals", set persistglobalsbetweensessions = true, or some other mechanism to support this? It's not just VO...

Yes, question is whether we want to do that on a per client-host basis (i.e. it is stored in a config file on the machine where gricli is installed) or "backend-wide" so each gricli-client that connects to that backend gets those.

We can do both, I'd opt for the former. Seems cleaner to me, but doing it backend-wide wouldn't bother me either...

Certainly client stored on our service makes sense, although I'd also suggest we log changes, as knowing what people are saving as defaults, or whether they're using that feature, would all be helpful. For example, we might find that people login, set their globals to the same, submit a job. If we see this, then we can find a way of short cutting this with setting defaults automatically (by default). Likewise, we could see common configs, or other interesting things.

But I'd prefer not to worry about a persistence mechanism at the backend for preferences just yet. File on the client seems simple, and effective for the hosted service

[makkus]

On 27/07/11 09:48, ndjones wrote:

Certainly client stored on our service makes sense, although I'd also suggest we log changes, as knowing what people are saving as defaults, or whether they're using that feature, would all be helpful. For example, we might find that people login, set their globals to the same, submit a job. If we see this, then we can find a way of short cutting this with setting defaults automatically (by default). Likewise, we could see common configs, or other interesting things. Hm, I think maybe if environment is the same after logout-login (just like they left it -- without them having to do anything) would be good? Seems intuitive to me. Most users would only have one group they use to submit jobs anyway, I'd imagine. Also, most of them would probably always use same application (and even version wouldn't change that often). Having an extra command to "store environment" would be one command that we could save the user to type. We could have "profiles" though. I think those are already possible though.

But I'd prefer not to worry about a persistence mechanism at the backend for preferences just yet. File on the client seems simple, and effective for the hosted service

Wouldn't be a worry, since both mechanisms are already implemented. One can store user properties on a backend, it's just one call to a java method. So both ways of doing it are cheap-as, technically. Just a question where/how/what we want to store...

[ndjones]

Right, well in that case then, I'd assume all Globals (though there are probably some that don't need to be).

One benefit of having them on the backend is that we can better manage the service. Perhaps if there is a local file for a user, that overrides the backend, but backend is default?

On 27/07/11 7:53 PM, "makkus" reply@reply.github.com wrote:

On 27/07/11 09:48, ndjones wrote:

Certainly client stored on our service makes sense, although I'd also suggest we log changes, as knowing what people are saving as defaults, or whether they're using that feature, would all be helpful. For example, we might find that people login, set their globals to the same, submit a job. If we see this, then we can find a way of short cutting this with setting defaults automatically (by default). Likewise, we could see common configs, or other interesting things. Hm, I think maybe if environment is the same after logout-login (just like they left it -- without them having to do anything) would be good? Seems intuitive to me. Most users would only have one group they use to submit jobs anyway, I'd imagine. Also, most of them would probably always use same application (and even version wouldn't change that often). Having an extra command to "store environment" would be one command that we could save the user to type. We could have "profiles" though. I think those are already possible though.

But I'd prefer not to worry about a persistence mechanism at the backend for preferences just yet. File on the client seems simple, and effective for the hosted service

Wouldn't be a worry, since both mechanisms are already implemented. One can store user properties on a backend, it's just one call to a java method. So both ways of doing it are cheap-as, technically. Just a question where/how/what we want to store...

Reply to this email directly or view it on GitHub: https://github.com/grisu/gricli/issues/105#issuecomment-1661948

[makkus]

This was implemented a while ago with @yuriyh implementing the saving of last used globals.