fricklerhandwerk/meta
1
0
Fork 0
forked from Fediversity/meta
Code Pull requests Activity

update roadmap following team meeting

Browse source
This commit is contained in:
Valentin Gagarin 2025-01-24 10:57:26 +01:00
parent 0edb62611b
commit e850e99e3d
2 changed files with 110 additions and 54 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

54
2024-01-mvp-demo-roadmap.md
View file

@ -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. <code>demo.fediversity.eu</code>
* 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

110
2025-01-24-mvp-demo-roadmap.md Normal file
View file

@ -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](./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](../meeting-notes/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 deploying a machine
- ...