There are multiple reasons and limitations with current tooling that we want to overcome.
We have abstracted all packages as custom resources and have a controller that reconciles these resources to (1) enable drift detection. Additionally, we use admission controllers (2) to validate dependencies and package configurations before they are applied to the cluster, while also working with custom resources to store and update the status of installed packages.
Genuinely interested. What problems did you have dealing with the standard reconciliation mechanism provided by ArgoCD and by k8s itself. I understand the advantage of the operator approach, but it might be hard to show the state in ArgoCD and somewhat breaks the idea of gitops.
Can we benefit your project in a more limited but agentless way? Limiting the types and CRDs we allow in k8s makes operations better, especially with the aggressive upgrade cycle that k8s already imposes.
A deeper integration into Argo CD (similar as how helm is integrated) will be needed to in order to display all status conditions.
I don't think that idea of gitops is broken if the glasskube package controller and all custom resources are versioned you will always lead to a reproducible result.
> Can we benefit your project in a more limited but agentless way?
We are building a central package repository with a lot of ci / cd testing infrastrucutre to increase quality of kubernetes packages in general: https://github.com/glasskube/packages
We have abstracted all packages as custom resources and have a controller that reconciles these resources to (1) enable drift detection. Additionally, we use admission controllers (2) to validate dependencies and package configurations before they are applied to the cluster, while also working with custom resources to store and update the status of installed packages.