Fleet auto-update: git-driven device reconcile #23
Labels
No labels
Compat/Breaking
Kind/Bug
Kind/Discussion
Kind/Documentation
Kind/Enhancement
Kind/Feature
Kind/Security
Kind/Testing
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Reviewed
Confirmed
Reviewed
Duplicate
Reviewed
Invalid
Reviewed
Won't Fix
Status
Abandoned
Status
Blocked
Status
Help Wanted
Status
Need More Info
Prio - Hoog
Prio - Laag
Prio - Middel
styling
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
MinBZK/DAWO-NixOS#23
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Managed devices should converge on new commits without a manual deploy. Propose a
dawo.autoUpdateblock (comin) following the #8 interface, that tracks a flake oncode.overheid.nl and rebuilds the device when commits land.
dawo.autoUpdate.options.repoUrlat its own overlay flake, which consumes thecore as an input, so the chosen overlay is pulled in on every update.
repoUrl(asserts non-empty),branch,pollSeconds(default 1800).services-comin.Question: is comin the right mechanism for the managed fleet, or do you prefer
deploy-rs push or
system.autoUpgradepull for the estate? PR follows the choice.@bram.buijs wrote in #23 (comment):
I prefer comin as this has a built-in Prometheus exporter. We can use this as device-update reporting in the future.
Secondly, comin has a command line interface that is available to users without sudo and allows for easy debugging.
Thirdly, comin has desktop notifications that will inform users on the updates as they come in.