kubebuilder-declarative-pattern VS controller-runtime

Hi, first time raising a post here. What are your thoughts on kubebuilder-declarative-pattern? My team and I has been working on our first k8s operator with operator-sdk for a while now, though it's only at the level of installation atm. Despite that, we found writing the simpliest Reconcilation logic of applying YAML idempotently to be complex enough and quite error-prone. (e.g. exposing a property to override `Service` resources name requires additional controller-logic to check if there's a service account of different name created previously and prune it to prevent dangling) . This is where I stumble across kubebuilder-declarative-pattern plugin, which has many nice features (e.g. apply --prune --applyset to address issue above), declarative-YAML and Reconcile logic out of the box.

operatorpkg is a set of packages used to develop Kubernetes operators at AWS. It contains opinions on top of existing projects like https://github.com/kubernetes/apimachinery and https://github.com/kubernetes-sigs/controller-runtime. In many cases, we plan to mature packages in operatorpkg before commiting them upstream.

however, at least in envtest this returns

(rejected) kubernetes-sigs/controller-runtime #2266 🐛 Support get config inside snap with SNAP_REAL_HOME

Check out https://github.com/kubernetes-sigs/controller-runtime/blob/main/pkg/client/example_test.go. It really is that easy :-).

I am using Kubernetes controller-runtime envtest.