Fediversity/meta
13
2
Fork 4
Code Issues1 Pull requests Projects Releases Packages Wiki Activity

Add meeting-notes/2025-03-26-demo-notes.md

Browse source 
Demo notes
This commit is contained in:
BjornW 2025-03-27 08:51:14 +01:00
parent 1bfc05f8de
commit 3bfbd9eece
1 changed files with 26 additions and 0 deletions

26
meeting-notes/2025-03-26-demo-notes.md Normal file
View file

@ -0,0 +1,26 @@
​**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