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:%24token@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
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.
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:%24
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.orgtest.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
On Mon, May 30, 2011 at 11:57 AM, Paul Larson paul.larson@linaro.orgwrote:
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:%24
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.orgtest.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
On Mon, May 30, 2011 at 6:54 AM, 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:%24token@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?
you could also register short names in the "git remote" style...
lava-tool add-farm myfarm http://mwhudson@validation.linaro.org
lava-tool submit-job --farm myfarm test.json
W dniu 30.05.2011 06:54, Michael Hudson-Doyle pisze:
Hi all,
$ lava-tool submit-job --farm https://mwhudson:%24token@validation.linaro.org test.json
This could then remember, bzr style, that it's is the farm you want to talk to. Unlike bzr the knowledge would be global (per user) so it would be stored in ~/.config/lava/... (unlike in git/bzr in some local directory).
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).
For a brief moment, yes. IMHO we should not care about this. If you want 'ps privacy' you can do that on a system wide level. If we really want we can supply some argument that will trigger /dev/tty interaction.
$ lava-tool submit-job --farm https://mwhudson@validation.linaro.org test.json --token Token for mwhudson@validation.linaro.org: ***********
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:
IMHO that should be python-keyring. Let's not reinvent .netrc again.
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?
Yeah. One more thing to think about though. Should lava-tool have per-command auth support (as in your examples above) or some side-band subcommands for auth that would be implicitly picked up by other commands (lava-tool auth ... && lava-tool submit-job ... VS lava-tool submit-job --auth-option ...)
Thanks ZK
On Mon, May 30, 2011 at 10:40:00AM +0200, Zygmunt Krynicki wrote:
$ lava-tool submit-job --farm https://mwhudson@validation.linaro.org test.json --token Token for mwhudson@validation.linaro.org: ***********
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:
IMHO that should be python-keyring. Let's not reinvent .netrc again.
Good point.
And for the problem of having to store a directory of farms, why not just encourage shell aliases:
lava-tool submit-job --farm $myfarm
Storing a default (on first use, maybe?) seems sensible:
lava-tool submit-job --farm $myfarm Storing https://mwhudson@validation.linaro.org in ~/.lava/default
lava-tool submit-job Using https://mwhudson@validation.linaro.org from ~/.lava/default
How does that look?
W dniu 30.05.2011 16:35, Christian Robottom Reis pisze:
Storing a default (on first use, maybe?) seems sensible:
lava-tool submit-job --farm $myfarm Storing https://mwhudson@validation.linaro.org in ~/.lava/default
You obviously meant to say:
Storing https://mwhudson@validation.linaro.org in ~/.config/lava/settings.conf
Let's not add another dot directory to ~. XDG config directories are far better for users and of no real change for developers.
lava-tool submit-job Using https://mwhudson@validation.linaro.org from ~/.lava/defaultHow does that look?
I like it, let's do it
Michael, would you like to do client-side auth or should I do it?
Thanks ZK
On Mon, May 30, 2011 at 05:30:53PM +0200, Zygmunt Krynicki wrote:
lava-tool submit-job --farm $myfarm Storing https://mwhudson@validation.linaro.org in ~/.lava/defaultYou obviously meant to say:
Storing https://mwhudson@validation.linaro.org in ~/.config/lava/settings.conf
Let's not add another dot directory to ~. XDG config directories are far better for users and of no real change for developers.
Good point; AAR, .lava/default was just intended as a suggestion.
On Mon, 30 May 2011 17:30:53 +0200, Zygmunt Krynicki zygmunt.krynicki@linaro.org wrote:
W dniu 30.05.2011 16:35, Christian Robottom Reis pisze:
Storing a default (on first use, maybe?) seems sensible:
lava-tool submit-job --farm $myfarm Storing https://mwhudson@validation.linaro.org in ~/.lava/defaultYou obviously meant to say:
Storing https://mwhudson@validation.linaro.org in ~/.config/lava/settings.conf
Let's not add another dot directory to ~. XDG config directories are far better for users and of no real change for developers.
lava-tool submit-job Using https://mwhudson@validation.linaro.org from ~/.lava/defaultHow does that look?
I like it, let's do it
I think I like this approach too. We could use short names as asac suggested too. That said, in my first branch I'll probably still require everything but the token to be provided on the command line.
Michael, would you like to do client-side auth or should I do it?
I was expecting to work on it. I have a few steps in the general direction in lp:~mwhudson/lava-tool/auth-support but kept running in to design issues :)
Cheers, mwh
On Mon, May 30, 2011 at 4:35 PM, Christian Robottom Reis kiko@linaro.org wrote:
On Mon, May 30, 2011 at 10:40:00AM +0200, Zygmunt Krynicki wrote:
$ lava-tool submit-job --farm https://mwhudson@validation.linaro.org test.json --token Token for mwhudson@validation.linaro.org: ***********
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:
IMHO that should be python-keyring. Let's not reinvent .netrc again.
Good point.
And for the problem of having to store a directory of farms, why not just encourage shell aliases:
lava-tool submit-job --farm $myfarm
Storing a default (on first use, maybe?) seems sensible:
lava-tool submit-job --farm $myfarm Storing https://mwhudson@validation.linaro.org in ~/.lava/default
lava-tool submit-job Using https://mwhudson@validation.linaro.org from ~/.lava/default
How does that look?
I prefer the ability to explicitly register shortnames for farms like I proposed further above.
We can also have a shortname "default" or so that would be used if you don't provide a --farm short-name ;).
Was there any argument against having shortname feature? or did you guys just ignore me ;)?
On Mon, May 30, 2011 at 07:04:46PM +0200, Alexander Sack wrote:
I prefer the ability to explicitly register shortnames for farms like I proposed further above.
What does this give you that shell aliases don't? If nothing but convenience, then it's probably just a nice-to-have.
W dniu 30.05.2011 19:04, Alexander Sack pisze:
I prefer the ability to explicitly register shortnames for farms like I proposed further above.
We can also have a shortname "default" or so that would be used if you don't provide a --farm short-name ;).
+1
Was there any argument against having shortname feature? or did you guys just ignore me ;)?
Just missed that, sorry.
Thanks ZK
On Mon, 30 May 2011 10:40:00 +0200, Zygmunt Krynicki zygmunt.krynicki@linaro.org wrote:
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:
IMHO that should be python-keyring. Let's not reinvent .netrc again.
Sure. I was talking design, not implementation :)
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?
Yeah. One more thing to think about though. Should lava-tool have per-command auth support (as in your examples above) or some side-band subcommands for auth that would be implicitly picked up by other commands (lava-tool auth ... && lava-tool submit-job ... VS lava-tool submit-job --auth-option ...)
I was thinking that there would be side-band commands such as auth-add, but I hadn't considered the point dreadfully hard.
Cheers, mwh
-
Alexander Sack -
Christian Robottom Reis -
Deepti Kalakeri -
Michael Hudson-Doyle -
Paul Larson -
Zygmunt Krynicki