Understanding generator.yaml Configuration This document describes the various configuration fields in a generator.yaml file that can be used to control the API inference and code generation for an ACK controller. We will show examples of configuring specific ACK controllers to highlight various configuration options. Generate a resource manager package For this section, we will use ECR as our example service API. When creating a new ACK controller, after running the controller-bootstrap program, you will be left with a generator.yaml that has all inferred API resources ignored.

Reference ACK Resource(s) In K8s Native Resource(s) Possibility of supporting cross namespace, infra in one namespace and application in another namespace Explore idea of annotations that export spec/status fields to configMap/Secret Explore idea of creating another CRD that creates a binding between ACK resource and K8s native resources Should existing service binding work be used or create our own CRD Should current resource reference UX be ungraded to line with generic resource reference? IOW, should referencing cross controller resources be done with service binding? Nick volunteered to do more research on the above ideas Important Links

Resource Relationship Brainstorming Notes Structure of the reference field Doesn't have to be backwards-incompatible. We can make a Go type that is JSON-serializable into a oneOf JSONSchema validation type. We did this for a "string or list of strings" type when adding functionality to the code generator for dealing with when fields in the generator configuration could be either a string or []string: https://github.com/aws-controllers-k8s/code-generator/blob/7dd0760fcd1cc03646423fb58b1bba773c795dfb/pkg/generate/config/operation.go#L82-L98 [x] Focus of introduction on use-case [x] Punt deletion for second revision [x] Add an usecase example in introduction(generator.yaml for apigatewayv2 route) [x] Scope down to same API group at the moment(main issue RBAC) [x] Consider adding selector for future

This document contains a collection of guidance for troubleshooting issues with ACK controllers. Deploying ACK controllers How ACK controllers are deployed (deployment + service + serviceAccount + CRDs + ClusterRole/Role and ClusterRoleBindings) Two ways of deploying controllers (raw manifests +kustomize or helm) Our recommendation is to use IRSA and Helm Emphasize that controllers can be installed on any Kubernetes cluster, not just EKS ones How to diagnose issues with ACK