26 lines
No EOL
2.2 KiB
Markdown
26 lines
No EOL
2.2 KiB
Markdown
**DEMO:** 2025-03-26 @09:30
|
||
**Present:** Bjorn, Gheorghe Loïs, Kevin, Hans, Eric, Kiara, Koen, Ronny, Valentin, Nicolas, Hans, Robert
|
||
|
||
**Demoed behavior**
|
||
* logged into the panel
|
||
* selected services to deploy, saved configuration
|
||
* clicked deploy button (observed NixOps4 working in the console)
|
||
* accessed pixelfed.fediversity.net and logged in with hard-coded user
|
||
* accessed mastodon.fediversity.net
|
||
* (un-deployed mastodon, still there; not part of the planned demo features)
|
||
|
||
**Demo notes (todo/actions/preperations)**
|
||
* Bjorn: from-scratch deployment takes a while (~400s), would need to talk a bit during the demo and explain what's happening at Fediforum
|
||
* Koen: in the final version we may want to display some install-tainment in the web view (in addition to the progress indicator), e.g. what one can do with the various services
|
||
* Progress indicator ideas (cherries on top)
|
||
* Count down from estimated time it will take
|
||
* Maybe show the progress log from CLI (advanced option?)
|
||
* Valentin: Should deploy to <service>.<user>.fediversity.eu (for a hard-coded username for now)
|
||
* And display the URLs in the panel (#264)
|
||
* Bjorn: Should log payloads sent to NixOps4 so we can explain a bit more of the inner workings
|
||
* Gheorghe: We may want imperative changes to service state or use a Staging Server as alternative for any special situation.
|
||
* Valentin: This would be purely a UX design issue mapping UI operations to the full-system declaration; the backend will still be declarative. We may need to consider performance/scheduling issues though, Kiara had opened issues regarding that
|
||
* Bjorn: For the demo on 1-2 April: would be great if we can also remove a service.
|
||
* Nicolas: Currently if we disable a service, NixOps4 is not informed of the existence of this resource and doesn't do anything about it; will rewire the deployment code today to fix that
|
||
* Eventually we'll need more state than enabled/disabled, e.g. diagnostics mode where a service keeps running but isn't exposed via DNS
|
||
* Nicolas: This would need to manipulate something different than the actual machine on which the service runs, such as the load balancer; this is currently not mapped out in the architecture so it would be a topic for later |