​**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