From cfdfbf59b04621cf63cea01908bac486bf25b565 Mon Sep 17 00:00:00 2001 From: Valentin Gagarin Date: Fri, 24 Jan 2025 10:57:26 +0100 Subject: [PATCH] update roadmap following team meeting --- 2024-01-mvp-demo-roadmap.md | 54 --------- meeting-notes/2025-01-24-mvp-demo-roadmap.md | 110 +++++++++++++++++++ 2 files changed, 110 insertions(+), 54 deletions(-) delete mode 100644 2024-01-mvp-demo-roadmap.md create mode 100644 meeting-notes/2025-01-24-mvp-demo-roadmap.md diff --git a/2024-01-mvp-demo-roadmap.md b/2024-01-mvp-demo-roadmap.md deleted file mode 100644 index 319b16b..0000000 --- a/2024-01-mvp-demo-roadmap.md +++ /dev/null @@ -1,54 +0,0 @@ -# Target: Demo at Fediforum online conference 2025-04-01 - -Goal: Demo Fediversity and make this demo available for download for others to use. -Focus on 1 or 2 Fediverse applications that can be 'automagically' installed aka a minimal viable product. - -To determine: - -- What are the minimal requirements to make this happen? -- What components are needed? -- Which Fediverse services are we going to offer? -- There are ~47 (~9weeks) workdays between 27-01-2025 and 01-04-2025. How will we divide the work among the team? - -# Roadmap - -* As a first measure, set up a new site with a simple email form: "set up your Fediverse services" - * Initial form fields: - * text field: subdomain to use under e.g. demo.fediversity.eu - * multi-select: services to deploy (start with one or two) - * text fields: ssh public keys - * freeform: additional requests - * Simply send an email to the project team for manual processing - * Figure out the rest as we go, automate time-consuming repetitive tasks incrementally - * Systematically keep procedural notes from which we can later derive code -* Split test environment into staging and production deployment -* Start preparing a Django service ([as discussed 2024-11-06](../meeting-notes/2024-11-06%20standup%20notes.md#working-session-architecture-discussion)) that will eventually replace the manually processed form - * It will take about a work week to make the development cycle smooth (maybe 2 weeks on the wall clock), enough to refine the initial data model - * It could trigger NixOps4 asynchronously on form submission - * Requires figuring out the exact interaction model on the backend. Especially how deployment state gets stored, retrieved, and updated - * Requires a Passbolt provider for dynamic secrets ([as discussed regarding secrets handling 2024-12-10](meeting-notes/2024-12-10-decision-making-meeting-dealing-with-secrets.md)) - * We probably don't want to mess with Git-backed storage there - * Requires a proper deployment provider - * Terraform is currently planned - * For single NixOS machines something more robust than a shellscript would already be nice, but that would require talking to Proxmox via API anyway -* Rebrand MyProtagio to Fediversity - * It currently interfaces with an intermediate registrar, need to remove that - * Demo users could register an actual domain using a voucher token -* Interfacing with MyProtagio for leveraging its DNS setup capabilities may need more time to study the code - * We’d ideally co-deploy an instance with the other front-end to enable smooth CI/CD; though that’s more up-front work - * MyProtagio doesn't have metering or billing yet - * If we hand out exactly one credit, it would include one domain name and some bulk service package for some period of time - -# TODO - -* Division of labor - * Tweag can do the domain-specific data types and transformations, as well as the the backend wiring - * Ronny asked to get involved in the domain modeling - * Waiting for Koen to contact their UI expert - * Robert needed for NixOps4 providers -* Selection of initial services - * Also have to resolve friction around versions being up to date in Nixpkgs - -# Next steps - -* Define detailed scope, integration points, schedule diff --git a/meeting-notes/2025-01-24-mvp-demo-roadmap.md b/meeting-notes/2025-01-24-mvp-demo-roadmap.md new file mode 100644 index 0000000..b27f8a5 --- /dev/null +++ b/meeting-notes/2025-01-24-mvp-demo-roadmap.md @@ -0,0 +1,110 @@ +# Target: Demo at Fediforum online conference 2025-04-01 + +This is a result of the [team discussion on 2025-01-23](https://git.fediversity.eu/Fediversity/intra/src/branch/main/2025-01-23-roadmap-discussion-fediforum.md). + +# Goal + +Demo the key aspects of Fediversity: +1. One-click deployment of Fediverse services +2. (stretch goal) One-click portability between hosting providers + +The point of the demo is to communicate: + - That the project extists, what it is about, how it's special, and that it's progressing towards its goals + - That this is the infrastructure you can use to provide a micro-cloud to end users + - The ultimate goal is infrastructure portability + - That we care about technological and economic sustainability + - For organisations that want to participate in the Fediverse, we may be a good partner + +Target audiences: +- Peers, potential clients, policymakers +- Hosting providers, organisations with sysadmins + +# Assumptions + +- There are ~47 (~9weeks) workdays between 27-01-2025 and 01-04-2025. + +- Demo users will use the Fediversity infrastructure. + + There are a few things we have to hard-code for now, so the backend setup won't be easily adopted by others, and this isn't the goal for the demo. + Eventually we'll also need to describe the infrastructure one needs to run the whole thing. + +- At this point it's not clear if we'll manage to enable service portability. + + Services ready to run on top of Garage: PeerTube, Mastodon, Pixelfed. + Making them portable is fairly involved though. + + [Galene](https://github.com/jech/galene) doesn't have any state and only needs configuration files to be ported over. + But it doesn't have a NixOS service yet. + Likely we we'll only need the Nix expression once we have it. + +# User story 1: Deployment + +- Log in with NixPanel +- Configure a DNS domain and select services to deploy +- Observe a progress indicator +- (optional) Get a notification when the process finishes +- Check that the services are accessible under the configured domain + +# User story 2: Migration + +- Log in on a different instance of NixPanel +- Create a migration token (e.g. callback URL) +- Paste the token in the first instance and start migration +- Observe a progress indicator +- (optional) Get a notification when the process finishes +- Check that the services run on the new instance + +# Roadmap + +* Set up a Django [CRM](https://en.wikipedia.org/wiki/Customer_relationship_management) service ([as discussed 2024-11-06](./2024-11-06%20standup%20notes.md#working-session-architecture-discussion)) + * Trigger NixOps4 on form submission: + * Requires a provider for the NixPanel to store deployment state and send progress updates + * Requires a Passbolt provider for dynamic secrets ([as discussed regarding secrets handling 2024-12-10](meeting-notes/2024-12-10-decision-making-meeting-dealing-with-secrets.md)) + * First step: assume a fixed provisioned setup + * For (optional) migratio: VM provisioning will be handled via Ansible for now: + * A NixOps4 Terraform provider is currently planned but will not be ready in time +* Rebrand MyProtagio to Fediversity + * Remove the intermediate registrar and register DNS domains ourselves + * Demo users will register an actual domain (and a bulk service package) using a voucher token + +# Next steps + +* Define: + * Detailed scope + + Which components need which capabilities to fulfill the user stories? + + Example: + - We need a Passbolt provider for NixOps4 + - We need a CRM to be set up and running, ready for triggering deployments + + * Specific division of labor + + Who exactly is responsible for which compononents? + Which time capcities are available for each contributor? + + Example: + - Tweag: Valentin will do the data modeling, Nicolas will wire up deployment-related Nix code + - Procolix: Hans will help integrate the existing Ansible script to spin up VMs on demand + - Robert will develop a provider for NixOps4 to interact with the CRM + + * Milestones (scheduled delivery of capabilities) + + What are the component capabilities we can test together? + When can we provide these aggregate capabilities? + + Example: + - Week 1: Spin up the CRM and configure a rudimentary data model + - Week 2: Let a fixed CRM user trigger NixOps to deploy a fixed config to a fixed existing VM + - Week 3: Configure SSH keys in the CRM, deploy to a fixed VM a NixOS config accessible with these keys + - ... + + * Issues (granular tasks) + + What exactly needs to be done to reach the milestones? + + Example: + - Deploy CRM + - Add UI for selecting a service + - ... +