Generate namespaced managed resources

[jbw976]

Description of your changes

This PR continues the work from draft PR #1689 that @negz started. It essentially updates this provider to start generating namespaced managed resources in addition to cluster scoped ones, which will be featured heavily in the current proposal of Crossplane v2.

This should not be taken as a final product. This is a practical update to this provider as a proof of concept for what we think a provider could look like in Crossplane v2. There are many short cuts taken, it is not production ready, and we are very open to feedback to change directions or improve the architecture.

The work in this PR should be merged into the new crossplane-v2 branch, which is based on commit 1ecd9cb, the latest commit when we started this work. We will need to rebase this effort in the future to include latest changes from main, but that should not block this PR.

I have:

• Read and followed Crossplane's contribution process.
• Run make reviewable to ensure this PR is ready for review.

General steps this PR has taken

The following list describes the general process that was taken to update this provider to support namespaced MRs:

• update to latest upjet version that supports namespaced resources
• duplicate content into both cluster and namespaced copies and make some minor updates for api groups and import paths
  • config, apis, controllers
• remove all legacy conversion/migration logic, because only the latest version needs to be supported
• update the provider main.go template to setup both cluster and namespaced apis and controllers
• update code generation comment markers to run on both cluster and namespaced types
• update the generator cmd to init both cluster and namespaced config to pass to code gen pipeline
• manually copy and update the handful of manual api and controller files to namespaced dirs

How has this code been tested

Besides generating, building and publishing successfully, this code has also been tested manually by installing the config, s3, rds, and ec2 packages into a control plane, then creating both cluster scoped and namespaced S3 buckets. Ex.:

❯ { head -n 1; grep '^buckets '; } < <(kubectl api-resources)
NAME                                        SHORTNAMES   APIVERSION                            NAMESPACED   KIND
buckets                                                  s3.aws.upbound.io/v1beta2             false        Bucket
buckets                                                  s3.m.aws.upbound.io/v1beta1           true         Bucket

❯ k get managed -A
NAMESPACE   NAME                                               SYNCED   READY   EXTERNAL-NAME             AGE
            bucket.s3.aws.upbound.io/crossplane-bucket-tmm54   True     True    crossplane-bucket-tmm54   21s

NAMESPACE   NAME                                                 SYNCED   READY   EXTERNAL-NAME             AGE
xp          bucket.s3.m.aws.upbound.io/crossplane-bucket-mhv6k   True     True    crossplane-bucket-mhv6k   18s

[jbw976]

Trying to fix the linter errors now, but that has been a bit tough due to the long cycles it takes to run, find issues, repeat :)

I don't have a solution for the failed check-examples test yet, looks like the examples dir is populated somewhat manually while testing a new resource, starting with the manifests from the examples-generated dir. I wonder if we can do something simple here...

[jbw976]

Just pushed a few commits that give me a clean make lint locally, c'mon CI! 🙏

[negz]

Could we switch everything to use aws.m.upbound.io?

I think that actually makes the most sense - since `m.upbound.io is the least specific part of the domain.

[jbw976]

sure, we can do that! that actually makes more sense for the root "config" group, as the xpkg batch assumes all of the CRDs for that group start with aws.*. Let's see how code gen like this update... 🙏

[jbw976]

This is now complete @negz, all the namespaced CRDs consistently use *.aws.m.upbound.io and I manually built/tested with the s3 provider 👍

[negz]

Just adding a note that we shouldn't merge this until we switch this to the crossplane/upjet crossplane-v2 branch after crossplane/upjet#480 is merged.

[negz]

@jbw976 why did you end up with config/namespaced/common/ and config/cluster/common`?

When we chatted with @ulucinar and @sergenyalcin I think we said we'd:

• Put most config only in common
• (Only) extend common with cluster-specific overrides in cluster
• (Only) extend common with namespace-specific overrides in namespaced

Is that still the plan long term?

[negz]

I focused on the hand-written commits in my review, and this looks like a good starting point. I'd like to get it merged so we can build an artifact and iterate.

[jbw976]

Is that still the plan long term?

Yes I think that is still the long term plan! I haven't tried any config consolidation into a common config yet in the interest of time.

why did you end up with config/namespaced/common/ and config/cluster/common`?

This is an artifact of there previously being a config/common that got moved down into config/cluster/common along with all the other previously existing config getting moved into a cluster subdir, and then copied over to config/namespaced/common as well. The code in that dir imports some types from apis, so as of now I still have the separate cluster and namespaced copies that import their corresponding api types.

There's not a ton of code in those common config dirs, so I reckon when we try to do a REAL common config dir it should be easy enough to make it work. Just haven't done any of that yet 😁

[jbw976]

I'm not sure what's going on with the linter check on this PR, make lint is passing consistently for me in ~14 mins, but it's timing out here after 2 hours. I suppose there is some local caching that I'm benefiting from on my laptop, as well as some extra CPU cores.

From my laptop:

❯ make lint
19:24:44 [ .. ] Running golangci-lint with the analysis cache building phase.
...
19:38:16 [ OK ] golangci-lint
19:38:16 [ .. ] Untagging source files.
19:38:18 [ OK ] Untagging source files.

I wonder if we need to continue investing in the strategy already in place from #1194, beyond what I've already done in this PR, to maybe filter out via build tags all the namespaced generated code, so we're not doing ~2x the linting? Or give the lint job a larger runner?

On main, it looks like lint already takes 1.5 hours, e.g. this recent run. Maybe a larger runner isn't a bad idea in general 😂

[jbw976]

yay lint passed in 1h40m with a larger runner, so it's not fundamentally broken, just resource constrained. Not an ideal long term solution, but perhaps enough to merge this and iterate 😂

Only unsolved item for the PR feedback and status checks is now check-examples.

[jbw976]

@negz, we got a green run here!! take a quick look again if you'd like at the latest manual commits to integrate all your feedback, to get linting passing by using a larger runner, and to exclude namespaced examples for now.

I am tracking all these shortcuts and will open issues later, don't worry about that! 😇