[deployer] One-click onboarding: add person + provision + install in one action (keep the per-step buttons too) #255

Closed
opened 2026-06-05 16:24:35 +00:00 by mik-tf · 1 comment
Owner

Right now an admin adds (or registers) a user, then clicks Provision, then clicks Install as three separate steps. For the common case we want a single action that does all three: fill the form once (username, plus name and email for a new account, plus the node, which is prefilled), click once, and the deployer registers the user, provisions the VM with its gateway and per-tester login, and installs the stack, showing staged progress (adding, provisioning, installing, ready) and finishing on a ready-to-copy cockpit URL. The existing per-step buttons stay on the user detail page so a failed step can be retried on its own and so you can still register someone now and provision later. The main work is graceful failure and progress rather than the happy path: provisioning can fail on the grid, so the combined action must stop at the failed stage and let the per-step buttons resume, and a brand new account must still surface its one-time password inside the combined flow. Start with the admin page chaining the existing calls (reusing the action spinner and the install-state badge) and only move the sequencing server-side if we need it to survive the admin closing the page. Sequence this after the welcome email (#236).

Signed-by: mik-tf mik-tf@noreply.invalid

Right now an admin adds (or registers) a user, then clicks Provision, then clicks Install as three separate steps. For the common case we want a single action that does all three: fill the form once (username, plus name and email for a new account, plus the node, which is prefilled), click once, and the deployer registers the user, provisions the VM with its gateway and per-tester login, and installs the stack, showing staged progress (adding, provisioning, installing, ready) and finishing on a ready-to-copy cockpit URL. The existing per-step buttons stay on the user detail page so a failed step can be retried on its own and so you can still register someone now and provision later. The main work is graceful failure and progress rather than the happy path: provisioning can fail on the grid, so the combined action must stop at the failed stage and let the per-step buttons resume, and a brand new account must still surface its one-time password inside the combined flow. Start with the admin page chaining the existing calls (reusing the action spinner and the install-state badge) and only move the sequencing server-side if we need it to survive the admin closing the page. Sequence this after the welcome email (https://forge.ourworld.tf/lhumina_code/home/issues/236). Signed-by: mik-tf <mik-tf@noreply.invalid>
Author
Owner

Plan locked, starting work. Building this as a single "Add and set up" action on the admin users page that chains the three existing steps (register or create the user, provision the VM with its gateway and login gate, install the stack) with staged progress and a copy-ready cockpit link at the end. The per-step buttons stay on the user detail page as the resume path for a failed or deferred step. The browser drives the existing calls in sequence; we only move sequencing server-side later if it has to survive the admin closing the page. A brand new account still shows its one-time password inside the flow, and the welcome email continues to fire only when the install finishes successfully.

We are also adding node capacity awareness, since the dedicated node has a finite number of slots and a failed provision can leave a contract to clean up. Each tester's basic bundle is a fixed size (2 slots, 8 GB), so we read the node's free and total slots and show "room for N more testers" on the form before you click, and we refuse a provision up front (cleanly, before anything is created) when the node is full or offline. This protects both the new one-click action and the existing manual Provision button.

Work items:

  • Three JSON endpoints on the admin server (create-or-register, provision, install) that return data instead of a rendered page, mirroring the existing status endpoints.
  • "Add and set up" primary button plus a staged-progress panel on the users page (adding, provisioning, installing, ready), reusing the existing status poll and action spinner.
  • Persistent one-time-password display for new accounts inside the flow, and a copy button for the final cockpit URL (no automatic clipboard write).
  • Stop-at-stage on failure, with a link to the user's detail page so the per-step buttons can resume.
  • Read-only node capacity endpoint (free slots, total slots, online status, room for N testers) feeding a live readout on the form.
  • Hard capacity preflight inside provision so a full or offline node is refused before any contract is created.
  • Verify end to end on the dedicated node by onboarding a throwaway tester with the new button, confirming the capacity readout, then tearing it down clean.

Signed-by: mik-tf mik-tf@noreply.invalid

Plan locked, starting work. Building this as a single "Add and set up" action on the admin users page that chains the three existing steps (register or create the user, provision the VM with its gateway and login gate, install the stack) with staged progress and a copy-ready cockpit link at the end. The per-step buttons stay on the user detail page as the resume path for a failed or deferred step. The browser drives the existing calls in sequence; we only move sequencing server-side later if it has to survive the admin closing the page. A brand new account still shows its one-time password inside the flow, and the welcome email continues to fire only when the install finishes successfully. We are also adding node capacity awareness, since the dedicated node has a finite number of slots and a failed provision can leave a contract to clean up. Each tester's basic bundle is a fixed size (2 slots, 8 GB), so we read the node's free and total slots and show "room for N more testers" on the form before you click, and we refuse a provision up front (cleanly, before anything is created) when the node is full or offline. This protects both the new one-click action and the existing manual Provision button. Work items: - [ ] Three JSON endpoints on the admin server (create-or-register, provision, install) that return data instead of a rendered page, mirroring the existing status endpoints. - [ ] "Add and set up" primary button plus a staged-progress panel on the users page (adding, provisioning, installing, ready), reusing the existing status poll and action spinner. - [ ] Persistent one-time-password display for new accounts inside the flow, and a copy button for the final cockpit URL (no automatic clipboard write). - [ ] Stop-at-stage on failure, with a link to the user's detail page so the per-step buttons can resume. - [ ] Read-only node capacity endpoint (free slots, total slots, online status, room for N testers) feeding a live readout on the form. - [ ] Hard capacity preflight inside provision so a full or offline node is refused before any contract is created. - [ ] Verify end to end on the dedicated node by onboarding a throwaway tester with the new button, confirming the capacity readout, then tearing it down clean. Signed-by: mik-tf <mik-tf@noreply.invalid>
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
lhumina_code/home#255
No description provided.