Part of epic #5954.

Task

Create Go types for the Terraform resource AccessContextManagerAccessLevelCondition.

Group: accesscontextmanager.cnrm.cloud.google.com
Kind: AccessContextManagerAccessLevelCondition
Version: v1alpha1

How to Create a CRD for an existing terraform resource

As part of moving resources from terraform controllers to direct controllers, we want to create a normal CRD using the controller-runtime framework.

These direct CRDs are defined with Go types under apis/<service>/<version>/<kind>_types.go. The service should not include the cnrm.cloud.google.com suffix, just the first component.

When we initially create the direct CRD, we want to make sure that we keep the same schema as the old Terraform CRD, for compatibility and so we can roll back. Ideally the generated CRD (under config/crds) does not change.
We accept some changes, more details below. You can easily see changes by running dev/tasks/diff-crds after running generate.sh.

For a CRD we are migrating from Terraform or DCL, we do not (initially) need a Mapper or Fuzzer; we accept or reject the PR based on the CRD definition. So send the generated mapper functions in your PR, but don't worry about a fuzzer yet.

Checklist for Coding Agent

We are able to generate a good starting point with some tooling we have created.

• Begin by creating or adding to the generate.sh script located in apis/accesscontextmanager/v1alpha1/generate.sh. (Please read apis/bigtable/v1alpha1/generate.sh for a good example to follow).
• Make sure you have added your resource (AccessContextManagerAccessLevelCondition) to generate-types.
• Run the generate.sh script. It should generate the shared types types.generated.go and a scaffolding for the types that cannot be generated, apis/accesscontextmanager/v1alpha1/accesscontextmanageraccesslevelcondition_types.go.
• Compare the CRD using dev/tasks/diff-crds. You will likely see some changes. Iterate on the types until they match.
• Most of the types will already be defined automatically under types.generated.go. Focus on <Kind>Spec and <Kind>Status (there is often a good starting point for the Spec and Schema types generated under types.generated.go).
• Ensure the controller-runtime annotations for the CRD have these labels:

  // +kubebuilder:metadata:labels="cnrm.cloud.google.com/managed-by-kcc=true"
  // +kubebuilder:metadata:labels="cnrm.cloud.google.com/system=true"
  // +kubebuilder:metadata:labels="cnrm.cloud.google.com/stability-level=stable"
  // +kubebuilder:metadata:labels="cnrm.cloud.google.com/tf2crd=true"

Acceptance Criteria (CRITICAL)

Running dev/tasks/diff-crds MUST NOT show differences (except for the acceptable changes listed below).

Acceptable changes:

• Field descriptions can change, particularly for metadata.
• status.observedGeneration will now be an int64.

Unacceptable changes:

• Changes to the schema itself, such as a field being added or removed, are NOT acceptable.

It is absolutely critical that running dev/tasks/diff-crds does not show differences in the schema.