AFWS interface

[thomasfire]

ARTIQ Feature Request

Problem this request addresses

Currently, obtaining binaries with AFWS is not frustrating only if you do not want to change the configuration of the system (i.e. just firmware updates). And even such, AFWS may introduce version confusion, because there is no mention of it in the documentation (I strongly doubt non-IT people will ever read usage message of the command). In any other cases, when they want to change the configuration and reflash the systems, they need to email us, which may take significant time, especially for those, who are in different time zones.

Describe the solution you'd like

Would be nice to have some kind of (graphical/web) interface, that would allow users to freely change their systems with respect to what they have on hands (in our databases). Here is non-complete list of suggested features:

• login into the account
• view systems and cards with configurations tied to the account
• move cards within crate
• move cards between crates
• move cards out and in the crate, in this case they would be "standalone"
• choose major/minor versions
• download JSON
• download firmware
• generate commands for flashing and configuration depending on their installation method
• (admins) add or delete cards/crates for the users
• large organizations can exchange cards within themselves
• subaccounts so that teams in labs can use it more conveniently without storing credentials in some shared place
• repair tracking?
• direct helpdesk? or some FAQ?
• history of configurations

Additional context

I would just say this seems to be better done in web, because with Qt we may have huge issues with deployment and accessibility.

[sbourdeauducq]

I strongly doubt non-IT people will ever read usage message of the command

Not everyone is lazy and inattentive. The target audience for ARTIQ is experimental scientists. It is reasonable to expect them to read the command help when they have any concerns, and pay attention. And this is also why it is important to have good help messages.

In this case, the version selection is pretty concisely explained by "--rev: revision to build (default: currently installed ARTIQ revision)". A similar comment could be added to --major-ver, and we could spell out that --rev wants a commit hash.

I would just say this seems to be better done in web, because with Qt we may have huge issues with deployment and accessibility.

We are deploying it together with artiq_dashboard and artiq_browser which use Qt, so this sounds like a non-issue.

Being able to do some changes to the configuration without manual intervention on our side sounds good. But most of your suggestions scream kichen sink syndrome. I'll close for now - please improve the client help messages and send a PR, think through a reasonable user reconfiguration interface and make another proposal for it.

[thomasfire]

The target audience for ARTIQ is experimental scientists.

Yes, they can reasonably be quite far from all the IT stuff, so that when we think it being "obvious" it regularly appears to be not so, and we can know this only from helpdesk - these folks will not ever appear in github or gitea. They may never studied CS at university, and even if studied, often it was some course of one language, which doesn't require Linux administration skills.

We are deploying it together with artiq_dashboard and artiq_browser which use Qt, so this sounds like a non-issue.

Unless you want to force update your clients. And also from my perspective doing good UI/UX in web is relatively faster.

scream kichen sink syndrome

With web service there is no need to release everything at once, because you can quite easily force-update it.