The key capability a GitOps tool can provide to declaratively deploy each of our CRDs is health checks. Most Production Grade Gitops tools have the logic necessary to monitor K8s native resources (Pod, Service etc), but also the flexibility to extend to any Custom Resource.
Both Flux V1 and V2 has good support for K8s native resources, which makes it a great tool for the average Arc-enabled Kubernetes Customers deploying K8s components that aren't Customer Resources.
For custom resources, Flux V2 has limited literature, as it offloads that responsibility to kstatus, which makes rigid assumptions about the fields a CR should emit to be considered healthy - a boolean called Ready. Due to there being no standardized pattern for this, many open source Operators and their Custom Resources do not support kstatus see example, and therefore cannot work with Flux V2 reliably.
In it's current standardized pattern, Arc Data Services CRDs cannot work with kstatus, and therefore Flux V2 and Arc-enabled GitOps:
kubectl get sqlmi sql-gp-ad-1 -n azure-arc-data -o json | jq .status
{
# kstatus looks for Ready : True
"state": "Ready" # , Error, Failed...
...
}It is also difficult for us to change these fields as there is a hierarchy defined in our decision record, and such changes would also break compatibility with existing customers.
Where ArgoCD health checks shine is, not only does it support all K8s native resources (StatefulSet, Pod etc.), for Custom Resources it lets you use Lua scripts to define arbitrary checks Argo Controller can execute against a K8s resource. Realizing this, a lot of companies that ship K8s Operator based products that cannot break backwards-compatibility have published their "official" Lua scripts in Argo's Github that ships right inside the Argo binary, meaning Argo "recognizes" the health of their CRD.