On Mon, May 30, 2011 at 11:57 AM, Paul Larson <paul.larson@linaro.org> wrote:

I think the long form of specifying the server is not terrible for now.  After all, aliases would make it a non-issue anyway.  Pulling from an environment variable should be simple, and iirc has already been done for lc-tool.  I think it's unlikely though, that one would commonly submit to moreb than one server frequently.  In the long run, I think it would be nice to consider a command to store a default server to submit the jobbto, if none is specified.


I like this idea of having a command to store the default values for a server.
We could also make the inputs more shorter if we required only the username to be passed on the command line and rest of the parts formed by picking up the things(for ex: https:// protocol, servername) from a file where the values would be stored. My guess is that one would mostly try to submit the things to a particular server and hence there would be no need to specify server name again on the command line.
Also, by providing the default values in a file we can provide an option to the user of either specifying new values from the command line or use the ones available in the file if nothing is specified on the command line.

Assuming the auth token has been previously stored, and the default server specified, that would simplify the command line to something like:


lava-tool submit-job test.json

Thanks,
Paul Larson

On May 29, 2011 11:54 PM, "Michael Hudson-Doyle" <michael.hudson@linaro.org> wrote:
> Hi all,
>
> I'm working on the infrastructure that will underlie the scheduler
> command line api. Zygmunt and I have the technical side understood I
> think, but what I want to think aloud about is how the command line
> should work for a user. In particular, I wonder how much state the
> command line tool should save.
>
> The basic command line entry point is "submit a job". For now at least,
> the job will be a JSON file, so the simplest possible invocation would
> be:
>
> $ lava-tool submit-job test.json
>
> But this doesn't specify anything about where the job should go. The
> least effort solution would be to require a full specification on the
> command line:
>
> $ lava-tool submit-job --farm https://mwhudson:$token@validation.linaro.org test.json
>
> This is clearly a bad idea though: tokens will be long and unwieldy and
> passing it on the command line means they will be disclosed in ways that
> we should avoid (they'll appear in ps output for all users and could
> easily end up in log files).
>
> So we need a way of storing tokens. The easiest thing to do would be to
> store a token for a (username, host) pair, so you'd run a command like:
>
> $ lava-tool auth-add --token-file token-file https://mwhudson@validation.linaro.org
>
> Then you'd still need to specify the username and host on every
> invocation:
>
> $ lava-tool submit-job --farm https://mwhudson@validation.linaro.org test.json
>
> Would this be too unwieldy do you think? For scripted or cronjobbed
> invocations its probably fine, for the command line it might be a bit
> awkward. But I don't know how much call there is for a genuinely
> interactive tool here.
>
> I guess the point I've argued myself to here is that I should implement
> this long form for now, and if a need arises add more conveniences (for
> example, reading from an environment variable or adding a command to set
> the defaults). Does anyone disagree too strongly with that?
>
> Cheers,
> mwh
>
> _______________________________________________
> linaro-dev mailing list
> linaro-dev@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-dev

_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev