Compare commits
2 commits
main
...
data-model
| Author | SHA1 | Date | |
|---|---|---|---|
|
cd0a53200a | ||
|
|
f9779723ed |
30 changed files with 41 additions and 11225 deletions
Documentation/WP2 Hosting
2025-03-03 D2.2 Software Release Beta Environment - Epics, User Stories, tasks and planning.pdf2025-03-05 FeDiversity Nix Backend Analysis Design Architecture Implementation and testing aspects.pdf
MarCom
architecture-docs
json-schema.yamlmeeting-notes
2025-03-03-progress-indicator-meeting.md2025-03-05 standup notes.md2025-03-06 standup notes.md2025-03-07 standup notes.md2025-03-10 standup notes.md2025-03-11 standup notes.md2025-03-12 standup notes.md2025-03-13 standup notes.md2025-03-17 standup notes.md2025-03-18 standup notes.md2025-03-19 standup notes.md2025-03-20 standup notes.md2025-03-24 standup notes.md2025-03-25 standup notes.md2025-03-25-visual-design-meeting.md2025-03-26 standup notes.md2025-03-26-demo-notes.md2025-03-27 standup notes.md2025-03-27_backend-model-conversion.md2025-03-31 demo rehearsel.md2025-03-31 standup notes.md2025-03-31-design-meeting.md
Binary file not shown.
Binary file not shown.
File diff suppressed because it is too large
Load diff
Binary file not shown.
|
|
@ -1,76 +0,0 @@
|
|||
# fediversity design meeting 2025-03-12
|
||||
|
||||
present: slik (thijs, tiemon) + procolix (lois, kevin, kiara)
|
||||
|
||||
- thijs: what is the project called and who does what?
|
||||
- thijs: how do you see front-end dev for this?
|
||||
- kiara: we don't need you to do an implementation using some front-end framework - just the design will do.
|
||||
- thijs: what will be the concrete deliverable then for the demo?
|
||||
- kiara: if for fediforum we do not have the design implemented yet that is acceptable.
|
||||
- thijs: maybe we will make it in time.
|
||||
- tiemon: sounds ambitious.
|
||||
- thijs: should we deliver code or would an interactive design do?
|
||||
- kiara: an interactive design will do.
|
||||
- kiara: could this handle animations too?
|
||||
- tiemon: yes.
|
||||
- thijs: could you explain some terminology here like fediverse, protagio, providers, panel?
|
||||
- kevin: *explains*
|
||||
- thijs: which applications will you do, and how do these get added?
|
||||
- kiara: mastodon, pixelfed and peertube at least.
|
||||
- kevin: *explains about fediversity sub-grants*
|
||||
- thijs: who will select what applications get added then?
|
||||
- kiara: formally the Open Internet Discourse Foundation.
|
||||
- thijs: are there set criteria for this? are these political decisions?
|
||||
- kiara: fediversity is open-source, tho as maintainers we will eventually need to make decisions take into account our capacity given the maintenance work involved.
|
||||
- thijs: how might hosts, users, workspaces and accounts relate?
|
||||
- kiara: we will offer SSO across applications.
|
||||
- thijs: what if people say use this from both professional as well as other roles? can they then have workspaces representing their accounts at different hosts?
|
||||
- kiara: i envision the web client as agnostic to orchestration capabilities, so a client application logged in to accounts at different hosts thru e.g. workspaces could technically be possible, tho i would not see this as significantly affecting our design currently.
|
||||
- thijs: how about a host admin panel to e.g. restrict offered applications? or for hosts' accountants?
|
||||
- kiara: hosts consist of sysadmins, so a config file may currently suffice for them as a user interface.
|
||||
- kevin: hosts also already have their own client-facing front-ends.
|
||||
- thijs: cli for now, so for the design focus on the operator panel? ok.
|
||||
- thijs: *asking about terminology*
|
||||
- *kevin + kiara explain*
|
||||
- thijs: do you want to offer a federated UX?
|
||||
- kevin: the deployed applications federate already.
|
||||
- thijs: applications tend to offer support buttons. who is in charge of offering this support, operators, hosts or you?
|
||||
- kiara: the operator, afaik.
|
||||
- kevin: we might direct users to the application manuals.
|
||||
- thijs: will fedipanel come with a knowledge base aimed at the operators?
|
||||
- kiara: we could link to a static one deployed from our end.
|
||||
- kevin: probably better to include this in the panel deployment.
|
||||
- thijs: sure, let me know.
|
||||
- thijs: we can show what we had so far in design program figma.
|
||||
- tiemon: you can navigate and interact with the designs, and they can generate html as well.
|
||||
- thijs: we like to work with job stories, so not just user stories like 'as a ...' but also including 'so that ...'.
|
||||
- kiara: great, so do we.
|
||||
- thijs: we can show some UIs we like for reference.
|
||||
- thijs: you won't offer file management from the panel, right?
|
||||
- kevin: correct.
|
||||
- kiara: fyi our deployment is somewhat big-bang still, rather than say configure mastodon -> deploy -> configure pixelfed -> deploy - we can not yet enqueue such syncs.
|
||||
- thijs: where can we find your application?
|
||||
- kevin: the code is at <https://git.fediversity.eu>, but we also have a recent demo video.
|
||||
- tiemon: we saw that one, yeah.
|
||||
- thijs: here is a wireframe so we can align on the chrome (= UI parts that are always there).
|
||||
- kiara: we do not yet have workspaces, but multiple deployments per user could become an option.
|
||||
- thijs: how about an admin interface to manage users?
|
||||
- kiara: we will have to go thru hosts' SSO because of billing.
|
||||
- kevin: yes this will go thru LDAP.
|
||||
- thijs: how about showing stats about e.g. numbers of mastodon users?
|
||||
- kiara: applications should already handle stuff specific to them, so we don't plan to do this.
|
||||
- thijs: how about application settings (generic vs application-specific)?
|
||||
- kiara: generic ones will apply to say configure VM resources or sub-domains, tho otherwise most should be application-specific.
|
||||
- thijs: no auto-scaling?
|
||||
- kiara: not for now.
|
||||
- thijs: how about a billing interface?
|
||||
- kevin: hosts would use their existing ones.
|
||||
- tiemon: how is pricing determined then?
|
||||
- kiara: hosts may set this based on the usage info we will provide.
|
||||
- thijs:
|
||||
- font: manrope?
|
||||
- kiara: looks pretty.
|
||||
- icon sets, selected by open-source / pretty / ...:
|
||||
- [iconoir](https://iconoir.com/)?
|
||||
- [phosphor](https://phosphoricons.com/)?
|
||||
- kevin+lois+kiara: this one looks prettier.
|
||||
|
|
@ -1,76 +0,0 @@
|
|||
# ssh access strategy
|
||||
|
||||
some notes on our current status, challenges and ways to address these
|
||||
|
||||
## questions
|
||||
|
||||
- [x] which keys do we accept on which users on which machines (infra/test)?
|
||||
- [x] when deploying (by nixops/tf, machines infra/test, separate/local/deployed), which user and key do we pass?
|
||||
|
||||
## background
|
||||
|
||||
<!-- - manual setup kevin -->
|
||||
<!-- - `nixos-24.05-minimal-x86_64.iso` -->
|
||||
<!-- - `users.users.procolix.openssh.authorizedKeys.keys` (procolix SSH jump nodes) -->
|
||||
- manual setup @niols
|
||||
- sync machines' `/etc/ssh/ssh_host_ed25519_key.pub` to:
|
||||
- `infra/test-machines/testxx/ssh_host_ed25519_key` (test machines)
|
||||
- `keys/systems/fedixxx.pub` (infra)
|
||||
|
||||
## challenges
|
||||
|
||||
- TF messing up non-root SSH access (`/etc/ssh/authorized_keys.d` absent)
|
||||
- TF not having a clear SSH strategy for production
|
||||
- machine key? how to select the right user/key? how does nixops handle this?
|
||||
- testing the panel locally not having a clear SSH strategy with password-protected SSH keys
|
||||
|
||||
## strategy
|
||||
|
||||
### which keys to accept on which users on which machines
|
||||
|
||||
- fedixxx/test0x
|
||||
<!-- - procolix -->
|
||||
<!-- - procolix jump nodes -->
|
||||
- root
|
||||
- fediversity team's individual keys
|
||||
- personal
|
||||
- personal (protected)
|
||||
- test0x: a passwordless wheel account (personal accounts? root too?) should allow also an unprotected ssh key (personal?)
|
||||
|
||||
### how to use SSH on deployment
|
||||
|
||||
#### user
|
||||
|
||||
(note that `desired` columns are focused on the scope of #76, so keeping e.g. security considerations out of scope.)
|
||||
|
||||
| context | current | desired |
|
||||
|-|-|-|
|
||||
| nixops infra | root | root |
|
||||
| nixops local | root | root |
|
||||
| protected? nixops panel local | root | root |
|
||||
| nixops panel deployed | root | root |
|
||||
| tf local | personal (hard-coded) | root |
|
||||
| protected? tf panel local | personal (hard-coded) | root |
|
||||
| tf panel deployed | personal (hard-coded) | root |
|
||||
| tf infra | root | root |
|
||||
|
||||
#### key
|
||||
|
||||
| context | current | desired |
|
||||
|-|-|-|
|
||||
| nixops infra | personal (thru ssh agent) | (protected) personal key |
|
||||
| nixops local | personal (thru ssh agent) | personal |
|
||||
| nixops panel local | personal (thru ssh agent, failed to handle password protection) | (unprotected) personal key |
|
||||
| nixops panel deployed | machine key (thru ssh agent) | machine key |
|
||||
| tf local | personal (thru ssh agent, password can be passed explicitly) | personal (unprotected, or if protected by passing it explicitly) |
|
||||
| tf panel local | personal (thru ssh agent, password can be passed explicitly) | personal (unprotected, or if protected by passing it explicitly) |
|
||||
| tf panel deployed | machine key (thru ssh agent) | machine key |
|
||||
| tf infra | n/a | (protected) personal key (with password propagated, somehow) |
|
||||
|
||||
## outcomes
|
||||
|
||||
added sub-tasks to:
|
||||
|
||||
- #272
|
||||
- #76
|
||||
- #274
|
||||
|
|
@ -1,7 +1,13 @@
|
|||
# migration data model requirements
|
||||
|
||||
To transfer between two providers, the target provider must be able to import the sending provider's versions. (e.g.: a deployment may have latest fediversity, latest pixelfed, but previous mastadon) Thus, for each "realease" of the data model, it needs to be versioned, and applications/APIs also are versioned.
|
||||
* (May need a way to show on the front-end which versions are in place, and which migrations are supported. However, for application versions which are completely controlled by the installation and setup, this is "solved".)
|
||||
(updated) deployment incl variables, backup creation/restore
|
||||
|
||||
<!-- To transfer between two providers, the target provider must be able to import the sending provider's versions. (e.g.: a deployment may have latest fediversity, latest pixelfed, but previous mastodon) Thus, for each "release" of the data model, it needs to be versioned, and applications/APIs also are versioned. -->
|
||||
<!-- * (May need a way to show on the front-end which versions are in place, and which migrations are supported. However, for application versions which are completely controlled by the installation and setup, this is "solved".) -->
|
||||
|
||||
Assumptions:
|
||||
|
||||
* Our deployment fully controls all versions, bypassing concerns on version mismatches.
|
||||
|
||||
for release version 0, focus on known current needs
|
||||
* to be expanded later as each new application is added and can be transferred between providers
|
||||
|
|
@ -10,101 +16,51 @@ for release version 0, focus on known current needs
|
|||
Specifically, this suggests scoping to migrating:
|
||||
|
||||
- managed infrastructure (rather than managed applications)
|
||||
- between servers owned by procolix
|
||||
- between servers initially owned by procolix
|
||||
- same proxmox version
|
||||
- NixOS VMs set up by us so we can guarantee identical application versions
|
||||
- hosting limited to a single application (to start)
|
||||
- retaining the same domain name
|
||||
- migrating the applications rather than also say control of domains
|
||||
|
||||
First, a bit of an inventory (list without much structure now, later will create structured form/schema with e.g. many-to-many links, useful for the migration code):
|
||||
* clearly mark items that will not be in the first migration as eventually or speculative
|
||||
* or reamove them if they would be too far in the future
|
||||
* later we understand what is useful for migration code, we can extract and transform in to a format suitable as data model documentation
|
||||
* clearly mark items that will not be in the first migration as planned for later or speculative
|
||||
* or remove them if they would be too far in the future
|
||||
* later we understand what is useful for migration code, we can extract and transform in to a format suitable as data model documentation
|
||||
|
||||
Hosting Provider provides:
|
||||
|
||||
* proxmox, git
|
||||
* hardware
|
||||
* filesystem storage
|
||||
* DNS automation hooks?
|
||||
* DNS automation hooks (RFC 2136, optionally authenticated by TSIG (RFC 2845) or GSS-TSIG (RFC 3645))
|
||||
* central/shared garage storage or only hardware+diskspace for the garage VMs to create storage?
|
||||
* with central: more efficient but less isolated
|
||||
|
||||
FooUniversity (Operator)
|
||||
* invoice info
|
||||
* is all info expected to be transferred from provider A to provider B?
|
||||
* May not want to transfer e.g. bank details, because they are already set up at B
|
||||
* May also depend on regulation (which information are you allowed to hand out?)
|
||||
* Admins:
|
||||
* credentials
|
||||
* persistent identifiers
|
||||
* mappings between them (also need to travel across providers)
|
||||
* e.g. if we can't change content URLs, we may need to create (and from then on carry around) a redirects mapping
|
||||
* those mappings are likely application-specific, but they all belong to the same type class
|
||||
* domain(s)
|
||||
* what is needed for DNS management?
|
||||
* users
|
||||
* display name
|
||||
* email(s)
|
||||
* login id
|
||||
* oauth2 (eventually)
|
||||
* 2fa
|
||||
* password
|
||||
* passkeys (eventually)
|
||||
* LDAP? (eventually?)
|
||||
* all applications
|
||||
* sub domain ( social.example.org vs example.org/social )
|
||||
* info for proxmox setup such as to provision VMs (to reproduce proxmox )
|
||||
* mem
|
||||
* cpus
|
||||
* storage mounts
|
||||
* IPs likely not the same in the target network
|
||||
* storage
|
||||
* filesystem
|
||||
* very well specified per application
|
||||
* blob storage config (garage, s3-like)
|
||||
* index
|
||||
* Can we make it a requirement that Garage is behind a predictable URL, eg. `<application>.garage.<customer domain>`? As opposed to something vendor-specific, eg. `pixelfed-university.garage.procolix.com/<customer domain>/<application>`
|
||||
<!-- * Can we make it a requirement that Garage is behind a predictable URL, eg. `<application>.garage.<customer domain>`? As opposed to something vendor-specific, eg. `pixelfed-university.garage.procolix.com/<customer domain>/<application>` -->
|
||||
* may need to rewrite URLs to blobs automatically, depending on the underlying URL scheme, which may be per setup or application
|
||||
* limits? per application? per user? where are these used/set/enforced?
|
||||
* TODO: what does e.g. borgmatic need to back up storage?
|
||||
* TODO: what does e.g. borgmatic need to back up?
|
||||
* complications: in case details such as connections change, those may need adjusting, implying application-specification reconfiguring
|
||||
* potentially propagate thru by e.g. TF?
|
||||
* out of scope?: focus on actual state, disregarding reconstructable stuff
|
||||
* SQL database
|
||||
* dump/snapshot
|
||||
* TODO: what does e.g. borgmatic need to back up databases?
|
||||
* application specifics
|
||||
* postfix? (is email in version 0?)
|
||||
<!-- * application specifics -->
|
||||
* pixelfed
|
||||
* where is blob storage
|
||||
* in the specific case of Pixelfed, if blob storage changed URL, we might need to rewrite the pictures URLs in the database (try to avoid this)
|
||||
* redis (in the case of pixelfed, it is not just a cache)
|
||||
* misc config: theme, name of instance, email of sysadmin
|
||||
* database
|
||||
* on-disk files
|
||||
* Daniel Supernault is currently making it so evertying can be stored remotely in a garage or sql database
|
||||
* users (login id) (in database? in redis?)
|
||||
* user preferences/settings
|
||||
* peertube
|
||||
* mastodon
|
||||
* matrix? (is it in version 0?)
|
||||
* logos
|
||||
<!-- * where is blob storage -->
|
||||
<!-- * in the specific case of Pixelfed, if blob storage changed URL, we might need to rewrite the pictures URLs in the database (try to avoid this) -->
|
||||
|
||||
Other considerations:
|
||||
When transforming the data-model code to a deliverable version of the data model as part of the technical architecture document, documenting user-data storage and with respects to security and GDPR
|
||||
|
||||
- Put a boundary for what is
|
||||
- operator-configurable
|
||||
- needs to get fixed, but at the implementation level
|
||||
- what can be configured dynamically per environment
|
||||
- Most importantly we need to preserve persistent identifiers
|
||||
<!-- See also: -->
|
||||
|
||||
- When transforming the data-model code to a deliverable version of the data model as part of the technical architecture document, documenting user-data storage and with respects fot security and GDPR
|
||||
|
||||
See also:
|
||||
|
||||
- possible overlap/inspiration: Stalw.art [configuration docs](https://stalw.art/docs/server/general)
|
||||
<!-- - possible overlap/inspiration: Stalw.art [configuration docs](https://stalw.art/docs/server/general) -->
|
||||
|
||||
## MVP scoping ideas
|
||||
|
||||
User story 1: New customer
|
||||
When a new customer goes to the Fediversity website we want to show that user what Fediversity is all about and what it can give to the customer. This points the customer to a signup form where they can enter all the details that are needed to get it working. Here they can also decide what applications to use (at first no more than three). Details can be, the user/admin login, name, address, bank details, domain, other users, and applications. Than when the customer hits the install/provision/go button everything starts to install automagically. After which the customer is presented with (some) url's to login to.
|
||||
When a new customer goes to the Fediversity website we want to show that user what Fediversity is all about and what it can give to the customer. This points the customer to a signup form where they can enter all the details that are needed to get it working. Here they can also decide what applications to use (at first no more than three). Details can be, the admin login, domain, and applications. Then when the customer confirms everything starts to install automagically, after which the customer is presented with (some) url's to login to.
|
||||
|
||||
User story 2: Take out / move to other instance
|
||||
At any time a customer may wish to change service providers. They can easily go to an admin screen where they can get their configuration and data packaged for transfer. This packaged data can be provided to a new service provider where they will be up-and-running again easily, with minimal downtime.
|
||||
|
|
@ -114,8 +70,8 @@ proposed MVP scope:
|
|||
- blob storage (garage)
|
||||
- physical servers
|
||||
- proxmox vm management
|
||||
- nixops service
|
||||
- nixops scripts
|
||||
<!-- - nixops service -->
|
||||
<!-- - nixops scripts -->
|
||||
- 1 to 3 applications packaged in Nix (Mastodon, Peertube, Pixelfed)
|
||||
- frontend / website
|
||||
- working dns, can be external, but automated
|
||||
|
|
|
|||
12
json-schema.yaml
Normal file
12
json-schema.yaml
Normal file
|
|
@ -0,0 +1,12 @@
|
|||
---
|
||||
type: object
|
||||
properties:
|
||||
# version:
|
||||
# type: number
|
||||
applications:
|
||||
type: object
|
||||
additionalProperties:
|
||||
type: object
|
||||
properties:
|
||||
# version:
|
||||
# type: number
|
||||
|
|
@ -14,8 +14,6 @@ For demo purposes until further notice, our parameters are a constant as far as
|
|||
|
||||
More important for now is having TF provider wrappers for common use cases, because that is where the application value lives
|
||||
|
||||
- kiara: i'm not sure i see TF wrapping as as important as nested deployment, fallback way if we need a TF step seems embed/use TF itself
|
||||
|
||||
On progress indication: NixOps4 is using the tracing library underneath, which offers separate events and spans (with start and end)
|
||||
|
||||
Adding JSON output is a quick fix
|
||||
|
|
|
|||
|
|
@ -1,29 +0,0 @@
|
|||
**Standup:** 2025-03-05 @09:30
|
||||
**Present:** Bjorn, Eric, Gheorghe, Koen, Lois, Valentin, Kevin
|
||||
**Absent:** Nicholas (known), Hans (known), Ronny (known), Kiara (Nix gathering)
|
||||
|
||||
* Bjorn
|
||||
* Yesterday: other obligations :(
|
||||
* Today:
|
||||
* Q: How is the work on deliverable 3 going? Demo on Monday 10th...
|
||||
* Eric
|
||||
* No blockers, no updates
|
||||
* Gheorghe
|
||||
* No blockers
|
||||
* Testerday: Internal PM activities
|
||||
* Today: Internal PM activities
|
||||
* Loïs
|
||||
* Looked at Kiara's feedback for fedipanel
|
||||
* No blockers
|
||||
* Koen
|
||||
* Spoke with Thijs and Timo and Kiara
|
||||
* I would like a general 'how to check an application' before sending it to NixPkgs discussion (not now).
|
||||
* Remy (EU thing)
|
||||
* Valentin
|
||||
* Pingponged code with Kiara yesterday, should merge basic handling versioned configurations today
|
||||
* Available for consultation and code review
|
||||
* Kevin
|
||||
* worked on the django yesterday resolving some comments from valentin in our pr
|
||||
* schedule for today is pretty full so probaly wont get much done for fediverse
|
||||
* Robert
|
||||
* No updates
|
||||
|
|
@ -1,37 +0,0 @@
|
|||
**Standup:** 2025-03-06 @09:30
|
||||
**Present:** Bjorn, Eric, Gheorghe, Koen, Lois, Ronny, Valentin
|
||||
**Absent:** Nicholas (known), Hans (known), Kiara (known)
|
||||
|
||||
* Gheorghe
|
||||
* No blockers
|
||||
* Yesterday: Internal PM activities + starting the central document for the Tweag back-end Nix creation.
|
||||
* Today: Internal PM activities + continuing the central document for the Tweag back-end Nix creation.
|
||||
* Koen
|
||||
* no blockers
|
||||
* no updates
|
||||
* Valentin
|
||||
* Discussed steps for demo preparation with Bjorn, Kevin, Lois
|
||||
* Continued tying up the data models in the backend
|
||||
* Reviewed the deliverables document Gheorghe prepared
|
||||
* Reviewed Robert's "modular services" PR
|
||||
* https://github.com/NixOS/nixpkgs/pull/372170/
|
||||
* Bjorn
|
||||
* Yesterday: spoke with Ronny, Valentin & with Kevin & Lois about the demo
|
||||
* Today: will speak with Koen.
|
||||
* TODO: will remove the old board
|
||||
* Loïs
|
||||
* Blockers: Needing a review on pr 141
|
||||
* Worked on MVP 2 preperation
|
||||
* Worked with Valentin and Kevin on versioned configurations
|
||||
* Today: Prepare further for demo 2
|
||||
* Eric
|
||||
* no blockers
|
||||
* available
|
||||
* Kevin
|
||||
* blocked on needing a review on the pr 141
|
||||
* Yesterday, met with loïs and Valentin to look at versioned configurations
|
||||
* also had a meeting with loïs, valentin and Bjorn for the mvp 2 next tuesday
|
||||
* This morning had a discusion with Loïs to prepare for the next demo
|
||||
* Ronny
|
||||
* Had a chat with Bjorn about structure
|
||||
* Preparing the partnermeeting on Friday
|
||||
|
|
@ -1,15 +0,0 @@
|
|||
**Standup:** 2025-03-07 @09:30
|
||||
**Present:** Bjorn, Gheorghe
|
||||
|
||||
|
||||
* Gheorghe
|
||||
* No blockers.
|
||||
* Yesterday: Internal project meetings and actions. Meet Erik and discussed more details about the documentation.
|
||||
* Today: Internal project meetings and actions.
|
||||
* Bjorn
|
||||
* Yesterday:
|
||||
* chat with Koen
|
||||
* cleanup Meta repo
|
||||
* Today:
|
||||
* partner status meetup
|
||||
* add daily standup notes to repo
|
||||
|
|
@ -1,26 +0,0 @@
|
|||
**Standup:** 2025-03-10 @09:30
|
||||
**Present:** Björn, Hans, Gheorghe, Ronny, Robert
|
||||
**Absent:** Koen (known), Kevin (known) Lois (known), Valetin (known), Nicolas (known)
|
||||
|
||||
* Björn
|
||||
* Friday:
|
||||
* Partners meeting
|
||||
* Standup (no more on Friday)
|
||||
* Today
|
||||
* Chat with Kiara?
|
||||
* Mail partners
|
||||
* Gheorghe
|
||||
* No blockers
|
||||
* Friday: Internal PM activities
|
||||
* Today: Internal PM activities
|
||||
* Hans (welcome back!)
|
||||
* planning to work on other projects than Fediversity
|
||||
* Robert
|
||||
* Did some prep work for improving flakes integration
|
||||
* Will not attend most standups until 27th (see wiki)
|
||||
* Will be available at Matrix for questions
|
||||
* Ronny
|
||||
* No blockers
|
||||
* No updates
|
||||
* Need to reschedule partnermeeting
|
||||
* Looking forward to demo tomorrow
|
||||
|
|
@ -1,32 +0,0 @@
|
|||
**Standup:** 2025-03-11 @09:30
|
||||
**Present:** Bjorn, Kevin, Koen, Kiara, Gheorghe, Lois, Eric, Ronny
|
||||
**Absent:** Hans (known), Valentin(known), Nicolas(known)
|
||||
|
||||
* Bjorn
|
||||
* Yesterday: partners mail
|
||||
* Today:
|
||||
* Demo
|
||||
* Going through planning
|
||||
* Chat with Kiara
|
||||
* Koen
|
||||
* fighting windmills (nix and debian). Start with learning the app on the OS it supports, than look at things like Nix.
|
||||
* Kevin
|
||||
* no updates:
|
||||
* today: doing the demo with lois en kiara
|
||||
* Kiara
|
||||
* Past days: Planet Nix
|
||||
* Today: continue triggering orchestration from panel, get back up to speed, maybe discuss roadmap
|
||||
* Gheorghe
|
||||
* No blockers
|
||||
* Yesterday: Internal PM activities
|
||||
* Today: Internal PM activities
|
||||
* Loïs
|
||||
* Today: Demo 2, discuss whats next
|
||||
* Past days: prepared for demo 2
|
||||
* Eric
|
||||
* No blockers, available
|
||||
* Ronny
|
||||
* No blockers
|
||||
* Looking forward to demo
|
||||
* Robert
|
||||
* no updates and now traveling listening in but noisy environment
|
||||
|
|
@ -1,19 +0,0 @@
|
|||
Standup: 2025-03-12 @09:30
|
||||
Present: Björn, Kiara, Eric, Kevin, Lois
|
||||
Absent: Koen (known), Gheorghe(known), Nicolas(known), Robert(known), Valentin(known), Ronny(known)
|
||||
|
||||
Updates:
|
||||
* Kiara:
|
||||
* Yesterday: paired on nixops from django with Lois
|
||||
* Today: ^
|
||||
* Bjorn
|
||||
* Yesterday: Demo & meetings
|
||||
* Today: going through work packages / deliverables & other obligations
|
||||
* Eric
|
||||
* available
|
||||
* Loïs
|
||||
* Yesterday: Demo 2, made a connection between panel and Nixops
|
||||
* Continue working on the panel today
|
||||
* Kevin
|
||||
* Yesterday: Demo 2 & after discussion
|
||||
* small talk a with koen about my availability
|
||||
|
|
@ -1,25 +0,0 @@
|
|||
**Standup:** 2025-03-13 @09:30
|
||||
**Present:** Bjorn, Lois, Kevin, Eric, Valentin, Kiara, Ronny
|
||||
**Absent:** Hans (known), Nicolas(known), Koen(known)
|
||||
|
||||
* Loïs
|
||||
* Yesterday: worked on deploying something with the fedipanel with Kiara, but we are having some nix issues.
|
||||
* Meeting with Thijs and Tiemon about the fedipanel design
|
||||
* Updated Kanban bord
|
||||
* Today: meet with Kiara, Kevin and Valentin?
|
||||
* Bjorn
|
||||
* Yesterday: Other obligations
|
||||
* Today: Other obligations
|
||||
* Eric
|
||||
* no updates, available
|
||||
* Kevin
|
||||
* Yesterday had a meeting with kiara, loïs and thijs and tiemon from slik about the design of the fedi panel
|
||||
* followed along a small bit with what kiara and loïs where doing
|
||||
* today: will work with loïs and kiara on de the panel
|
||||
* around 12:00 i will leave with koen to leiden again
|
||||
* Kiara
|
||||
* Yesterday: design meet, trigger nixops from django (#246) w/ lois
|
||||
* Today: continue on trigger nixops from django
|
||||
* Valentin
|
||||
* No updates
|
||||
* Has some time to pair with the devs today
|
||||
|
|
@ -1,20 +0,0 @@
|
|||
_Notes re-created as I was not fast enough to download them before the session was ended_
|
||||
|
||||
**Standup:** 2025-03-17 @09:30
|
||||
|
||||
* Kevin
|
||||
* Thursday: troubleshooted the forgejo with eric after an reboot the notifications work again
|
||||
* Friday: no updates
|
||||
* Today: give valentin dns access. moslty will do procolix stuff but try to do some small fedi stuff inbetween
|
||||
* Valentin
|
||||
* At ocean sprint this week
|
||||
* Thursday: Discussed code review items with Kiara, studied deployment code to clarify next steps, went through new issues Kiara opened
|
||||
* Kiara
|
||||
* Past day: work on triggering orchestration from the panel w/ @lois
|
||||
* Today: continue on this
|
||||
* Björn
|
||||
* Friday: partners meeting, talk with Koen.
|
||||
* Today: other obligations
|
||||
* Ronny
|
||||
* Partners meeting
|
||||
* Today: other stuff
|
||||
|
|
@ -1,26 +0,0 @@
|
|||
**Standup:** 2025-03-18 @09:30
|
||||
**Present:** Bjorn, Eric, Lois, Kevin, Ronny, Valentin, Kiara
|
||||
**Absent:** Koen(known), Robert(known), Gheorghe(known), Nicolas(known), Hans(known)
|
||||
|
||||
_Note: please do *not* press 'end meeting for all'_ 😉
|
||||
|
||||
* Björn
|
||||
* Yesterday: only standup
|
||||
* Today: worksession with Ronny updating the deliverables
|
||||
* Loïs
|
||||
* Thursday: worked with Kiara on deploying Fedipanel
|
||||
* Today: continue working on the fedi panel with Kevin
|
||||
* Valentin
|
||||
* Talked with Robert about the SSH issues encountered while trying to deploy, pushed half of a workaround
|
||||
* Kiara
|
||||
* Yesterday: locally orchestrate from panel
|
||||
* Today: deploy panel able to orchestrate
|
||||
* Kevin
|
||||
* Yesterday spend a few hours going through all the work i have for procolix and planning them so I have more time now this week to fully work on fediverse from today to thursday
|
||||
* So today i will be working on the on the panel with Loïs again
|
||||
* Eric
|
||||
* helped kevin to get forgejo notifications working again
|
||||
* available
|
||||
* Ronny
|
||||
* Yesterday: standup
|
||||
* Today: worksession with Bjorn updating deliverables
|
||||
|
|
@ -1,31 +0,0 @@
|
|||
**Standup:** 2025-03-19 @09:30
|
||||
**Present:** Eric, Lois, Kevin, Ronny, Koen, Kiara
|
||||
**Absent:** Gheorghe (known), Nicholas(known)
|
||||
|
||||
**Updates**
|
||||
* Eric
|
||||
* available
|
||||
* Lois
|
||||
* Yesterday: worked on the progess indicatorwith kevin
|
||||
* Today: Continue working on the progress indicator
|
||||
* Kevin
|
||||
* Yesterday: worked with loïs on the progress indicator
|
||||
* Today
|
||||
* morning bit busy with other stuff have to take my cat to the vet for vacination
|
||||
* the rest of the day will continue with kiara en lois on the indicator and the panel
|
||||
* Ronny
|
||||
* Worked with Bjorn on the deliverables.
|
||||
* Had a conversation with Eric about outreach
|
||||
* Had an internal NLnet converation about the project
|
||||
* Koen
|
||||
* No blockers
|
||||
* today: level with Kiara and Lois and Kevin (afternoon)
|
||||
* Valentin
|
||||
* Fixed panel deployment code, now accessible under https://demo.fediversity.eu
|
||||
* Reviewed Kiara's code
|
||||
* Kiara
|
||||
* Yesterday: distilled pr for local deploy button, continue on getting it to work in production
|
||||
* Today: continue on deploy button in production
|
||||
* Björn
|
||||
* Yesterday: worked on deliverables with Ronny & spoke with Koen. Tried to get some work done on the communication strategy
|
||||
* Today: other obligations
|
||||
|
|
@ -1,24 +0,0 @@
|
|||
**Standup:** 2025-03-20 @09:30
|
||||
**Present:** Bjorn, Eric, Lois, Kevin,Valentin, Kiara, Koen
|
||||
**Absent:** Ronny (known), Gheorghe (known), Hans(known), Nicholas(known)
|
||||
|
||||
* Kevin
|
||||
* Yesterday: worked with Loïs and kiara to get a pogress spinner working in the panel
|
||||
* Today: work on the feedback and see whats next
|
||||
* Kiara
|
||||
* Yesterday: work on orchestration from panel online
|
||||
* Today: work on orchestration from panel online
|
||||
* Lois
|
||||
* Yesterday: got the progress indicator to work
|
||||
* Today: work on some of the feedback from Kiara gave for the progress indicator
|
||||
* Valentin
|
||||
* Reviewed the deployment triggering PR
|
||||
* Followed up with async questions
|
||||
* Conversations at Ocean Sprint on all sorts of rather mid-to-long-term topics (architecture ideas for building UI on top of NixOS modules, approaches to solve systemic issues in the Nix ecosystem)
|
||||
* Koen
|
||||
* 2 candidates in 'sight'
|
||||
* Eric
|
||||
* available
|
||||
* Bjorn
|
||||
* Yesterday: Standup, no communication strategy.
|
||||
* Today: Announcement on website of participation at Fediforum. Other obligations
|
||||
|
|
@ -1,43 +0,0 @@
|
|||
**Standup:** 2025-03-24 @09:30
|
||||
**Present:** Bjorn, Kevin, Ronny, Robert, Kiara, Koen, Gheorghe, Nicholas, Valentin
|
||||
|
||||
|
||||
* Ronny
|
||||
* Friday partnermeeting
|
||||
* Today, uploading deliverables
|
||||
* Kiara
|
||||
* Past day(s): live deployment (weekends: by TF)
|
||||
* Today: tbd?
|
||||
* Koen
|
||||
* Lois, Kevin and Kiara are all coming to Fediforum.
|
||||
* Lois will do the demo and will be supported by Kevin and Kiara
|
||||
* Looking to hire one or two more senior people
|
||||
* Pixelfed 'not waiting for Daniel'
|
||||
* Kevin
|
||||
* Thursday: Something came up for procolix so i had to quickly help with that
|
||||
* Friday: procolix day
|
||||
* Today: on order of koen work on Pixelfed.com and plan the rest of my week
|
||||
* Valentin
|
||||
* Last week: fixed deployment and small scale productivity issues, code reviews and tactical implementation discussions with Kiara in between Ocean Sprint activities
|
||||
* Had a very productive MVP milestone 3 planning meeting with Kiara, Lois, Kevin last Thursday
|
||||
* This week: will continue with code reviews and catching up with Nicolas
|
||||
* Bjorn
|
||||
* Friday: partner meeting
|
||||
* This week:
|
||||
* Today: Other obligations
|
||||
* Tuesday: Other obligations; Who will take over DSU?
|
||||
* Wednesday: demo & Fediversity & continue with deliverables (communication strategy)
|
||||
* Thursday: half a day Fediversity & continue with deliverables (communication strategy)
|
||||
* Friday: project partners meeting
|
||||
* Gheorghe
|
||||
* No blocker
|
||||
* Last week: Internal PM activities
|
||||
* Today: Internal PM activities
|
||||
* Robert
|
||||
* Completed OceanSprint: good vibes between Nix implementers. Glad to have contributed to that after rough year. Community can heal.
|
||||
* Merged Kiara's fix
|
||||
* Made some progress on resource state
|
||||
* Aeolus: modeling state transitions in NixOS by Ma27
|
||||
* Nicolas (sorry :p)
|
||||
* back from holiday
|
||||
* will spend the day catching up
|
||||
|
|
@ -1,35 +0,0 @@
|
|||
**Standup:**
|
||||
**Present:** Bjorn, Kevin, Ronny, Robert, Kiara, Koen, Gheorghe, Nicholas
|
||||
**Absent:** Robert, Valentin, Bjorn (excused)
|
||||
|
||||
Status:
|
||||
|
||||
* Loïs
|
||||
* Thursday: Worked on the progress indicator with Kiara
|
||||
* Today: Meeting with Slik with Kevin and Kiara
|
||||
* Nicolas
|
||||
* lots of catching up after holiday
|
||||
* Working on integration test (potentially with Selenium) at least trying to run NixOps
|
||||
* Kevin
|
||||
* Worked on the pixelfed.com instance waiting for daniel for s3 storage connection details
|
||||
* did some planning on my tickets have allot of procolix but i probably alteast have half today for fediverse
|
||||
* Gheorghe
|
||||
* No blockers
|
||||
* Yesterday: Internal PM
|
||||
* Today: Internal PM
|
||||
* Kiara
|
||||
* Yesterday: deploy button, debugging versioning for MVP
|
||||
* Today: deploy button, design meeting
|
||||
* Ronny
|
||||
* No blockers
|
||||
* Yesterday reporting and recording podcast
|
||||
* Today deliverables
|
||||
* Koen
|
||||
* was interviewed by Fedivariety
|
||||
* will try to 'push' Daniel to give stuff faster
|
||||
* 16 and 17 april are 'go'
|
||||
* remark about design meetings
|
||||
* Eric
|
||||
* no blockers,
|
||||
* hopeful to meet with Ronny today for Fediversity visibility
|
||||
* available
|
||||
|
|
@ -1,40 +0,0 @@
|
|||
# Fediversity design meeting 2025-05-25
|
||||
|
||||
Present: {thijs,timon}@slik, {lois,kevin,kiara}@procolix
|
||||
|
||||
- timon: *demonstrates design*
|
||||
- timon: i already selected some relevant icons, selected colors for dark/light themes together with one accent color, a kind of professional blue. for branding the application we could either offer a pre-set selection of colors, or a color picker.
|
||||
- thijs: we can also display recent releases, e.g. to show newly released versions of mastodon.
|
||||
- kiara: it isn't obvious we can always update deployed applications automatically, as deployments involve user-selected options that may be non-trivial to migrate, potentially requiring new user choices - tho it may also be desirable to just give users more agency in choosing when to update applications, sooner or later.
|
||||
- thijs: maybe we could let users select updating policies separately by application.
|
||||
- kiara: in the future, perhaps.
|
||||
- thijs: will you write update posts, or the hosts?
|
||||
- kiara: maybe we could just link to the application developers' release notes, but on the other two... eventually both, maybe?
|
||||
- thijs: as for billing, does it make sense to show a 'used disk' meter with an upgrade button?
|
||||
- kiara: capacity such as disk space may in part be bound to deployed applications, tho for other parts like immutable storage we may be able to just meter actual usage, rather than requiring space be reserved upfront.
|
||||
- thijs: maybe you could also offer hosts different options for the billing.
|
||||
- timon: i made a help button including an FAQ, knowledge base and support. for the search field, would we like context-sensitive or general search results?
|
||||
- kiara: eventually context-sensitive as well, altho we haven't really gotten to the point of thinking about search so far.
|
||||
- timon: i also added an 'install app' button (maybe just app-specific install buttons), and notifications categorized like releases / changelog.
|
||||
- thijs: so the notifications can be categorized this way.
|
||||
- timon: the install button i imagined to be at the host level, so they can choose whether to install and offer an application to their operators.
|
||||
- kiara: the target audience of this web interface are the operators, as hosts already had the skills to install these applications.
|
||||
- thijs: hosts could instead use a config file to enable/disable certain applications.
|
||||
- timon: ok, then this button can be removed.
|
||||
- timon: what applications might you offer down the road?
|
||||
- kiara: *mentions some open-source and fediverse applications*
|
||||
- timon: how about number of applications?
|
||||
- kiara: operators could have multiple deployments, each of which could have different applications deployed.
|
||||
- timon: should we incorporate this into the design using a workspace switcher?
|
||||
- kiara: maybe, although i could imagine views where deployed applications might be grouped by such a deployment as well.
|
||||
- thijs: i think you could prevent various concerns by letting users focus on a single workspace at a time for now, in case these say pertain to different clients of theirs.
|
||||
- timon: we also made a mock-up for an application detail page, e.g. a mastodon one with some general description, potential user actions, maybe update/action history logs.
|
||||
- timon: the mock-up for the install view shows different steps, some sample toggles.
|
||||
- kiara: so far the designs have focused on a desktop setting, had you already considered responsiveness for e.g. mobile displays?
|
||||
- thijs: we will eventually work on a mobile setting as well, yeah, but the desktop case is easier to present, if not probably our first use-case here.
|
||||
- thijs: maybe koen will have some feedback as well.
|
||||
- lois: could you maybe send him the design already?
|
||||
- thijs: in fact, it can be found [at this link](https://www.figma.com/proto/AZbFAac2Xjxs3q1H3orXzO/Fedi-Design-system?page-id=97%3A1682&node-id=104-1754).
|
||||
- kiara: *mentions challenges wrt visualizing diffs in configurations / options*
|
||||
- TODO@procolix: offer example options for e.g. mastodon.
|
||||
- lois: i'll send an invite for the meeting with koen.
|
||||
|
|
@ -1,36 +0,0 @@
|
|||
**Standup:** 2025-03-26 @09:30
|
||||
**Present:** Bjorn, Gheorghe Lois, Kevin, Hans
|
||||
**Absent:** Koen (known), Ronny (known), Nicolas(known)
|
||||
|
||||
* Gheorghe
|
||||
* No blockers
|
||||
* Yesterday: Internal PM activities
|
||||
* Today: Internal PM activities
|
||||
* Hans
|
||||
* No updates
|
||||
* Working on non-Fediversity stuff for bit
|
||||
* Loïs
|
||||
* Yesterday: demo preperations, fixing the merge conflicts so that pr 259 can be merged into main.
|
||||
* Today: demo
|
||||
* Kevin
|
||||
* Yesterdat prepared for the mvp with loïs en kiara. did some final changes to the pr hoping it can me merged into main before the demo
|
||||
* still waiting on de s3 details from daniel for the pixelfed
|
||||
* today: demo
|
||||
* Kiara
|
||||
* Yesterday: demo env button, test Mastodon to make user and toot
|
||||
* Today: demo env button
|
||||
* Björn
|
||||
* Yesterday: other obligations
|
||||
* Today: working a bit on deliverables
|
||||
* Valentin
|
||||
* Monday:
|
||||
* Synced with Nicolas, sketched next steps for the Nix backend
|
||||
* Started with a simple JSON Schema -> module options conveter, read up on Clan's module options -> JSON Schema converter
|
||||
* Code reviews; deployment from panel not possible (reasons pointed out by Kiara in the issue tracker)
|
||||
* Internal meeting
|
||||
* Robert
|
||||
* No updates
|
||||
* Eric
|
||||
* No updates
|
||||
|
||||
|
||||
|
|
@ -1,26 +0,0 @@
|
|||
**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
|
||||
|
|
@ -1,31 +0,0 @@
|
|||
**Standup:** 2025-03-27 @09:30
|
||||
**Present:** Bjorn, Gheorghe, Eric, Hans, Nicolas, Ronny, Kiara, Kevin, Loïs
|
||||
**Absent:** Koen(known), Valentin(known)
|
||||
|
||||
* Björn
|
||||
* Yesterday: mostly preparing for Fediforum. Did everyone saw the mail?
|
||||
* Today: Not much Fediversity
|
||||
* Gheorghe
|
||||
* No blockers
|
||||
* Yesterday: Internal PM activities
|
||||
* Today: Internal PM activities
|
||||
* Kiara
|
||||
* Yesterday: deploy from prod
|
||||
* Today: deploy from prod
|
||||
* Kevin
|
||||
* yesterday: demo and after discussion found going very well
|
||||
* today: got assigned multiple tasks from koen that suddenly have to be finished so no fediverse work for me
|
||||
* Eric
|
||||
* available
|
||||
* Hans
|
||||
* No updates or blockers
|
||||
* Still working on non-Fedi stuff
|
||||
* Nicolas
|
||||
* worked on disabling machine configurations - PR today
|
||||
* worked on integration NixOps deployment test (without FediPanel for now) - no blockers
|
||||
* Ronny
|
||||
* Ospology yesterday, where we also presented Fediversity a bit
|
||||
* Lois
|
||||
* Yesterday: Demo, Talked over the demo for Fediforum
|
||||
* Today: Continue working on the panel to prepare for Fediforum
|
||||
|
||||
|
|
@ -1,96 +0,0 @@
|
|||
# Architecture notes on backend data model conversion
|
||||
|
||||
These aspects have been discussed ad hoc between Kiara, Nicolas, and Valentin over the past two weeks, and this is to keep a record of our considerations.
|
||||
|
||||
We previously left some scattered notes in [2025-02-26 architecture discussion](../meeting-notes/2025-02-26-architecture-discussion.md) (Nicolas, Kiara, Valentin), but had some ongoing ad hoc back and forth in the background.
|
||||
|
||||
## Problem space
|
||||
|
||||
- We'll have to deal with version drift eventually:
|
||||
- Once a configuration is deployed and we update the Fediversity software (which will likely include a Nixpkgs update), the configurable options may be different.
|
||||
- We're maintaining our own simplified configuration layer on top of regular NixOS, because our services need to be wired with Garage.
|
||||
This means we have quite a lot of control over the shape of the interface, but not over the semantics since the underlying service may still change, however subtly.
|
||||
- It's likely we'll mostly *add* information, but we may also remove configuration options, or change their structure or meaning.
|
||||
- Under the assumption that we won't force-upgrade operators' deployments, we somehow need to display that difference between what's currently deployed and what can be configured and then deployed
|
||||
- This is not a problem if the data type for the configuration didn't change, because then it's simply a difference in value
|
||||
- If the options for configuration change, it's a difference in type
|
||||
- We could also use the opportunity to display something like release notes inline with the configuration changes, where we could explain why something changed, right where we display the change in structure.
|
||||
- A prototype for storing versioned configurations was implemented in the following commits:
|
||||
- [e41f9c572](https://git.fediversity.eu/Fediversity/Fediversity/commit/e41f9c572a9e76f6c009a4fc407ed58d183684f8)
|
||||
- [9dd92b4cc](https://git.fediversity.eu/Fediversity/Fediversity/commit/9dd92b4cc180e88ffc14a96ec979a90c84e1676f)
|
||||
- [981ba011a](https://git.fediversity.eu/Fediversity/Fediversity/commit/981ba011abb4bdf9230048bda4e9af2a96be40cf)
|
||||
|
||||
The idea is very similar to Django migrations, but at the level of JSON fields:
|
||||
- Keep Python data structures around as modules for each version; those are supposed to be never changed
|
||||
- Remember the version stored as JSON using a regular database field
|
||||
- Take the right version's module when parsing the JSON value from the database
|
||||
- The display code (HTML template, form behavior, etc.) is stored together with the data model
|
||||
|
||||
Not implemented was an equivalent of Django's `FormView` but for Pydantic schemas, which would generate forms automatically and could be adjusted in detail to have control over presentation.
|
||||
Since configurations can have nested data structures for services, each of which may progress in version at different paces, we could also store versions per service to avoid code duplication; this wasn't sketched in the prototype, merely noted in comments.
|
||||
|
||||
As opposed to Django database migrations, the difference between schemas would be determined from the code (like snapshots) rather than from the database state.
|
||||
- These diffs could be computed automatically and then stored for manual adjustments
|
||||
- This would keep around both snapshots and diffs, but the diffs need to encode semantics and presentation
|
||||
- With the diffs ready, one may as well discard the snapshots, but we can expect the diffing code to be rather hard to read
|
||||
- Django avoids the pile-up of snapshots by only ever caring about exactly one database state.
|
||||
- We can't simply throw away old schemas since there may be an arbitrary number of versions deployed or configured by all operators
|
||||
- We would need to determine which versions are still in use before garbage-collecting old schemas
|
||||
- Working with these configuration schema migrations can be expected to require some discipline, likely more than with regular database migrations, since they also affect presentation of at least two different schemas at once
|
||||
- We also considered simply not caring about the whole versioning problem, but Valentin insists it will bite us before long and that we should exercise dealing with it far before going live.
|
||||
- Another aspect is state migrations between deployed versions for each service, which would need to be handled at the service layer.
|
||||
- This is a well-known, rather hard problem, and has been [covered by academic research](https://upsilon.cc/~zack/talks/2017/2017-11-27-hdr.pdf)
|
||||
- We won't go into this in the forseeable future, but eventually it needs to be properly solved at sufficient scale to avoid mounting maintenance burden
|
||||
|
||||
These changes were reverted in [08d109cc8](https://git.fediversity.eu/Fediversity/Fediversity/commit/08d109cc826c2979af104af0919c75143bd79616), unfortunately without noting the reason.
|
||||
|
||||
- Kiara had proposed using some Django equivalent of [react-jsonschema-form](https://rjsf-team.github.io/react-jsonschema-form/) to render the front-end automatically from the underlying data model
|
||||
- Valentin is opposed to the idea on multiple grounds:
|
||||
- Under the assumption that we want a rather lightweight front-end in terms of amount of JavaScript loaded and executed in the browser, most of the work would need to happen on the server
|
||||
- This would require the conversion to forms to happen in Django
|
||||
- Most likely we'd want to use [DRF form rendering](https://www.django-rest-framework.org/topics/html-and-forms/#rendering-forms) on top of Pydantic models for that
|
||||
- We could generate the Pydantic models at build time with https://github.com/koxudaxi/datamodel-code-generator
|
||||
- The devshell could even place the generated files next to the code, where can be inspected as needed
|
||||
- There's https://github.com/georgebv/drf-pydantic for automatically generating serialisers
|
||||
- At that point it's unclear what we need the JSON schema for, because we may as well work directly with Pydantic models
|
||||
- With JSON schemas, we have no fine-grained control over presentation
|
||||
- There still would need to be a layer for adjusting spatial arrangement (such as sequence of fields)
|
||||
- That would need to be done for each schema version, and versioning will be part of our application logic
|
||||
- Again, it seems like it would make more sense to manage that centrally, in one language and with one representation of the data model, and simply display the result at the Django interface (HTML forms augmented with htmx, optionally JSON+REST if needed)
|
||||
- Another question is whether we would start with JSON schemas or merely use them to pass around information about types.
|
||||
- Valentin argues: if the browser is not supposed to handle application logic, we never need to pass around type information
|
||||
- The only place where we'd be forced to use JSON schemas is if we generated the front-end data model from our NixOS modules
|
||||
- Arguments against a standalone client-side application:
|
||||
- It duplicates application logic we already have, and costs effort we could spend on developing the application itself
|
||||
- We don't expect to ever deliver anything else than the web front-end, and Django gives us JSON+REST essentially for free anyway
|
||||
- Keeping separate application state in the browser is a can of worms we don't have the capacity or team experience to deal with on the current timeline, and dealing with it wouldn't help address our business problem
|
||||
- We can get dynamism with htmx at much less mental overhead than a client-side application, a fraction of compute requirements in the browser, and none of the supply chain hassle
|
||||
|
||||
- Another can of worms is bridging the gap between the Nix backend and the (in this case Django) frontend
|
||||
- Clan developers already spent time with the problem and wrote a [module options to JSON schema converter](https://clan.lol/blog/json-schema-converter/)
|
||||
- The general issues is that the module system is substantially more expressive than JSON schemas
|
||||
- The problem is not that we *need* that expressive power, but that avoiding it requires care
|
||||
- Generating schemas requires taking particular care when writing front-facing modules
|
||||
- Nicolas proposed using a safe subset of `lib.types`
|
||||
- Valentin: We could go even further and write a type library explicitly compatible with [JSON schema validators](https://json-schema.org/draft/2020-12/json-schema-validation)
|
||||
- Avoiding laziness (such as `mkIf`) would still be on implementers
|
||||
- This can work but may be brittle due to leaving opportunities for human error
|
||||
- It's likely to be the most pragmatic approach for the forseeable future, since JSON schemas provide a reasonable collection of common types
|
||||
- Putting in a JSON-schema-safe layer would be ideal, and will likely benefit the Nix ecosystem a lot by unlocking independent experimentation with UIs, but may require a non-trivial time investment.
|
||||
- We'd then store all versions of the option declarations so we can read them back in the front-end
|
||||
- Alternatively we could only keep the generated Python classes and the presentation code, because that's the only thing we'll need later
|
||||
- In trat case we should have Git hooks, CI checks, and possibly a check at startup to ensure the generated code corresponds to the module options
|
||||
- There's some recent work in the direction of [diffing module options and values](https://oceansprint.org/reports/2025/#nixos-module-system-enhancements) which we may be able to leverage for at least partially auto-generating version diffs
|
||||
- Alternatively we could take the opposite direction and parse JSON schemas into module options
|
||||
- This is how the current prototype works, except we don't even have a module or schema but simply expect the data structure to have a certain shape
|
||||
- That's just an interim hack, and placing a module type at the interface promises to ease error analysis in tests
|
||||
- It has the advantage that invalid expressions cannot be constructed, avoiding future friction entirely
|
||||
- We can live with rather simple type checking at the module layer since the front end would do good-enough input validation already
|
||||
- The main disadvantage is that the dependency is flipped: we'd have to model our back-end business logic (service configuration interfaces) in what would then exist as part of the front-end code
|
||||
- The coupling between our service layer and NixOS is rightfully tight, and having a media gap due to a different language will incur mental overhead and slow down iteration and testing.
|
||||
- The build setup will also get rather confusing because we'd have to first invoke the front-end code to wire up the back-end with the front end...
|
||||
|
||||
- Conlusion for next steps:
|
||||
- Generate JSON schemas from our front-facing NixOS modules
|
||||
- Work towards a JSON schema type library for module options, gain practice with safe usage patterns
|
||||
- Generate a Python data models from JSON schema, and work with forms from there
|
||||
|
|
@ -1,31 +0,0 @@
|
|||
**Demo rehearsel:** 2025-03-31 @10:00
|
||||
**Present:** Kiara, Koen, Ronny, Kevin, Gheorghe, Robert, Bjorn, Valentin, Nicolas, Hans
|
||||
**Absent:** Eric (known)
|
||||
|
||||
__Agenda__
|
||||
* Koen starts with presenting
|
||||
* Kevin will present the demo
|
||||
|
||||
__Presentation & Demo notes__
|
||||
* Financed by EC, not "being" from EC.
|
||||
* I suggest to say Prototype and not Product for now.
|
||||
* I thought we were going to use the coloured EU flag(@Ronnynote: Koen is using an older version of the pdf.../ auch, okay)
|
||||
* We need a bit more 'what is the mvp about'/'what is the demo about'
|
||||
* s/Hello world/Welcome
|
||||
* First show that the apps are not deployed yet. Let people visit the urls themselves
|
||||
* Can we make the split screen in demo wide, instead of long? (@kevinnote: yes but this was only normal sized monitor i have at the moment)
|
||||
* Because of the elementary graphical interface, maybe a lower resolution of display will make the command text greater.
|
||||
* When speak about the interface would be nice to have it visible on the screen.
|
||||
* The argument for having ops done by professionals needs some polish => we are targeted at organisations (if you can run your own hardware, go!)
|
||||
* Why skip slides? Will not skip.
|
||||
* benefits providers: these are the benefits FOR providers
|
||||
* Maybe don't switch between the presentation & demo. It's a bit distracting. (hans: I think that's a good thing, it breaks it up in different bits that makes it a bit more lively)
|
||||
* I would suggest to add in the benefits and the other images also the Services offered to the Users to give the whole image of the prototype.
|
||||
* The architecture diagram is an old one. The NixPanel is no more there.
|
||||
* Nix is not an operating system ;..)
|
||||
* roberth: One term keeps it simple and is good enough
|
||||
* Nix is a system for building software more reproducibly
|
||||
* The old NixPanel in the architecture is not mapped by the Django(Python) description.
|
||||
* People can't write comments on Forgejo without an account, and there's no way to register
|
||||
* Why not Develop & contribute Django (Python) in How to participate?
|
||||
* Incantation -> Incarnation
|
||||
|
|
@ -1,33 +0,0 @@
|
|||
**Standup:** 2025-03-31 @09:30
|
||||
**Present:** Kiara, Koen, Ronny, Kevin, Gheorghe, Robert, Bjorn, Valentin, Nicolas
|
||||
**Absent:** Hans (known), Eric (known)
|
||||
|
||||
* Kiara
|
||||
* Past day(s): continue on deploy button online
|
||||
* Today: investigate SSH strategy for above and to deal with password-protected SSH keys
|
||||
* Koen
|
||||
* now have some experience with pixelfed
|
||||
* want to upgrade the pixelfed cluster this afternoon and bring it live this evening so we can announce it tomorrow before the conference
|
||||
* Kevin
|
||||
* Worked on the panel friday, it shows now if the deploy was a succes and which services have been deployed
|
||||
* today can work more on the panel but dont know what yet will discuss with kiara
|
||||
* Bjorn
|
||||
* Friday: Partnermeeting
|
||||
* Today: demo & prep for Fediforum
|
||||
* Valentin
|
||||
* Wrote up design discussion on configuration data model versioning and format conversion
|
||||
* Internal meetings
|
||||
* Nicolas
|
||||
* Last week disabling the machine
|
||||
* Working on reproducing the NixOps4 upstream deployment test
|
||||
* Got stuck with providing DNS within the sandbox
|
||||
* Robert: there's some code I can give you for that
|
||||
* Gheorghe
|
||||
* No blockers
|
||||
* Friday: Internal PM activities
|
||||
* Today: Internal PM activities
|
||||
* Ronny
|
||||
* Good partnermeeting on Friday
|
||||
* Robert
|
||||
* Finishing up flake input override support (needed for ad hoc testing, generally useful)
|
||||
* Next: stateful resources
|
||||
|
|
@ -1,47 +0,0 @@
|
|||
# Visual design meeting 2025-03-31
|
||||
|
||||
Present: {thijs,timon}@slik, {koen,kevin,kiara}@procolix
|
||||
|
||||
- thijs: updated the designs as per the last meeting, supporting workspaces, dark/light themes, (implied) usage graphs, future fediverse services, updated theme
|
||||
- koen: maybe categorize services using tags, e.g. fediverse, productivity, chat, video, microblogging
|
||||
- thijs: so allow filtering by this too?
|
||||
- koen: yes
|
||||
- kiara: i like the new design
|
||||
- koen: KDE's designs looks pretty, maybe also look at that
|
||||
- timon: *clicks mastodon install, leading to detail page*
|
||||
- koen: maybe allow batch selecting to install, as in current barebones technical implementation
|
||||
- koen: please add icons for more applications
|
||||
- timon: *showing preview page for mastodon*
|
||||
- koen: again, minimize needed clicks, e.g. using basic vs advanced install rather than 'install' vs 'manage', then allow users to maybe tweak after
|
||||
- thijs: then just do 'install' vs 'manage' as you probably don't want non-basic installs, so people can tweak after
|
||||
- koen: you should be able to just use them when installed, afterwards change 'install' button to like 'go to your instance'
|
||||
- koen: i like the detail page's log view, may end up long tho, so maybe add a 'show more' ellsion
|
||||
- timon: fleshed out the settings view, as well as a users list
|
||||
- thijs: the users list is more an example of a CRUD page, as you mentioned wanting to do SSO/LDAP before
|
||||
- koen: again, distinguish stuff everyone should see vs advanced settings we by default should not bother busy non-technical users with
|
||||
- thijs: you have not configured a domain yet, so cannot deploy mastodon yet - we should probably nag people on mandatory settings they have yet to set, also show progress bar for this
|
||||
- koen: start simple, then show everything when desired
|
||||
- thijs: different ways to not scare people off, not sure scaring people with advanced settings is the way, you could instead just show optional settings
|
||||
- koen: still sounds scary
|
||||
- thijs: otherwise may not notice what you can do with it
|
||||
- thijs: you may not know a user's role up-front
|
||||
- koen: start as basic user
|
||||
- thijs: sysadmins will feel confused tho
|
||||
- koen: maybe ask in the onboarding / sign-up what role you want
|
||||
- thijs: onboarding, what else?
|
||||
- thijs: we made sure to use only open-source fonts and icons
|
||||
- koen: i see some details we will not use: e.g. pricing plans ending in 99, pricing plans worded to sell rather than offer transparency (wording shown in design: 'perfect' without elaboration as to why), pricing that needs explaining so people can understand why they should not feel ripped off
|
||||
- kiara: isn't usage much more fungible?
|
||||
- koen: we should show those from the panel, but there are different ways to approach this as per an operator's business model
|
||||
- thijs: maybe hosts should get to choose how to approach this
|
||||
- koen: agree, companies will have limited resources and may prefer to not make things too granular, tho in larger set-ups one may need to be able to better justify how pricing scales
|
||||
- thijs: do we always want to add a link to the price/value breakdown for every plan?
|
||||
- koen: by default yes, if you don't want that, it's open-source so you can fork if you like
|
||||
- thijs: thanks - what else should we change for tomorrow?
|
||||
- koen: maybe add graphs over time on disk space and number of applications deployed
|
||||
- kiara: actually whether the background looks grey or white-ish for me depends on which monitor i view it on
|
||||
- thijs: ok let's make it a bit lighter still
|
||||
- koen: maybe also add user settings like advanced/novice, allow scrolling thru the app list, add an icon as per fediversity.eu (NGI - fediversity)
|
||||
- koen: from pic 'many branches of the fediverse' use: lemmy, bookwyrm, funkwhale, friendica, castopod, writefreely, matrix, owncast, peertube, forgejo, passbolt
|
||||
- kiara: this image already shows potential tags too
|
||||
- thijs: we'll try and add the configurable color themes too
|
||||
Loading…
Add table
Reference in a new issue