Talking to lava-server is very error prone
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
LAVA Tool |
Won't Fix
|
High
|
Zygmunt Krynicki |
Bug Description
The UI for interacting with lava-server (and any of its parts) with lava-tool (and any of its extensions) is horrible UI wise.
I propose the following design instead:
1) Use easy-to-remember URLs, make them invisible
2) Use bookmarks
3) Handle the login & token parts so that users don't have to invent messy solutions themselves
A few examples:
EXAMPLE 1
Logging in to a lava server. The same workflow we currently do with auth-add. A few things to note:
1) The user provided a bookmark (we'll ship it by default) to the public validation lab and his launchpad username
2) The token was created and confirmed with a single click through the browser
3) The username was remembered, any access to that server will be authenticated form now on (there is no extra URL to remember here!)
$ lava login add zkrynicki bookmark:
Note: bookmark "validation-lab" resolves to https:/
A browser window was opened, please sign in and confirm the request.
Press ENTER when you are done with the web parts
...
Confirming token, done!
You are signed in as Zygmunt Krynicki
EXAMPLE 2
Adding another bookmark to the system. Here the staging instance. A few things to notice:
1) We can check the URL for correctness, we can go out and talk to the server too
2) We can remember the fixed URL, users knew they made a mistake and get educated
3) We can have many bookmarks, most users will have one, maybe two
$ lava bookmark add staging https:/
Note: you missed the trailing slash (fixed)
Ensuring that provided URL works: yes
Saved as "staging", use bookmark:staging when you want to interact with that server.
EXAMPLE 3
Since almost everyone will use just one server having a default bookmark seems like a nice way to solve the UI issue.
$ lava bookmark default staging
Switching your default bookmark (the server that we'll talk to to) "staging"
There are 3 other bookmarks, see lava bookmark --help to know more.
EXAMPLE 4
Posting a scheduler job:
$ lava submit job my-job.json
Using default bookmark "validation-lab"
...
Job submitted as job 4123
(see https:/
EXAMPLE 5
Posting a dashboard bundle:
$ lava submit bundle my-bundle /anonymous/
Using default bookmark "validation-lab"
...
Stored as bundle 4995feb019e1a45
(see https:/
Full command set:
lava login add - login to a remote lava server with the provided username, obtain and store the security token
lava login list - list all security credentials remembered on this machine
lava login remove - remove an authentication token from this machine (and optionally remove it on the server)
lava bookmark list - list all bookmarked lava-servers
lava bookmark add - add a bookmark
lava bookmark remove - remove a bookmark
lava bookmark default - display or change the default bookmark
lava submit XXX - submit an object to LAVA (currently bundles and test jobs)
Required lava-server methods:
system.public_key() -> returns the public key of the server
system.
system.whoami() -> returns the user identity, useful for checking tokens
Affects:
linaro-
lava-server
lava-tool
lava-dashboard-tool
lava-scheduler-tool
Changed in lava-tool: | |
status: | New → Confirmed |
importance: | Undecided → High |
Changed in lava-tool: | |
assignee: | nobody → Zygmunt Krynicki (zkrynicki) |
Changed in lava-tool: | |
status: | Confirmed → Won't Fix |
I don't know about the name "bookmark" for this, but I think this is originally how we talked about wanting this to work early on - where you could define known servers by name, and set a default to use. And good job writing up and clearly defining the idea - but could we please convert it to a blueprint instead? This seems like something that should be a BP, not a bug.