Closed jpds closed 3 months ago
Yes, i agree this doesn't look nice :/ Thank you for this review: I need to find a better wording.
I'm actually not sure comin is GitOps, since when there is a manual change on the infra, comin doesn't detect it and doesn't reconcile it. (That's why it didn't want to use this term.)
However, comin could be close enough to GitOps to be referred as "GitOps".
Also, it would not be hard to make comin watching the deployed NixOS configuration to reconcile it in case of a manual switch. I'm however not sure it would be useful in practice, excepting to be able to claim comin is GitOps ;)
since when there is a manual change on the infra, comin doesn't detect it and doesn't reconcile it
What do you mean by "reconcile" ? https://fluxcd.io/ is the original GitOps tool and if you make a manual change to the infra - it simply looks at what's in Git and overrides the manual change made (enforcing that the Single Source of Truth
is what's in the Git repo).
What do you mean by "reconcile"
I mean resolving divergences between the state of the infra and the configuration. As you say, flux overrides manual changes: this is not something comin is able to do. So i considered comin doesn't have all properties of a GitOps tool.
Thank you for raising this issue: I finally updated the readme as you suggested.
flux overrides manual changes: this is not something comin is able to do
Right, the reason I asked the "reconcile" clarification was that I assumed the nixos-rebuild
stage would perform this override stage.
Looks great now!
Early flux and gitops in Kubernetes also struggled with proper reconciliation of which resources were created by whom, so I would not be afraid to use language such as "reconcile" at such an early project stage as it provides philosophical goals when technical decisions are yet to come.
The README is confusing in that it says push and then immediately pull:
The title should probably be changed to "GitOps for NixOS Machines":