Create containerattached Cluster resource

[RedbackThomson]

Description of your changes

Adds the google_container_attached_cluster resource to a newly created containerattached group

I have:

• Read and followed Crossplane's contribution process.
• Run make reviewable to ensure this PR is ready for review.
• Added backport release-x.y labels to auto-backport this PR if necessary.

How has this code been tested

I was able to e2e test this by creating an EKS cluster with an OIDC issuer (using the XEKS composition from configuration-aws-eks). I copied the output OIDC Issuer URL into oidcConfig.issuerUrl, set the platformVersion to the newest version supported for the 1.28 Kubernetes cluster, and updated the distribution to eks.

Here is a redacted version of the manifest I applied:

apiVersion: containerattached.gcp.upbound.io/v1beta1
kind: Cluster
metadata:
  labels:
    testing.upbound.io/example-name: primary
  name: primary
spec:
  deletionPolicy: Delete
  forProvider:
    authorization:
    - adminGroups:
      - <redacted>
    description: Test cluster
    distribution: eks
    fleet:
    - project: projects/<redacted>
    location: us-west1
    loggingConfig:
    - componentConfig:
      - enableComponents:
        - SYSTEM_COMPONENTS
        - WORKLOADS
    monitoringConfig:
    - managedPrometheusConfig:
      - enabled: true
    oidcConfig:
    - issuerUrl: <redacted>
    platformVersion: 1.28.0-gke.3
    project: <redacted>

[jeanduplessis]

/test-examples="examples/containerattached/v1beta1/cluster.yaml"

[turkenf]

Hi @RedbackThomson,

Thank you for your effort to add this resource. We currently do not have a mechanism to automatically test this resource. Therefore, we need to test manually and add manual intervention annotation to the resource YAML file.

Let me explain the manual test steps:

• As you mentioned, we need EKS or AKS cluster for the spec.forProvider.oidcConfig.issuerUrl parameter of the Cluster.containerattached resource. I did the test using AKS, but it is similar for EKS.
  • Install family provider provider-azure-containerservice
  • Create the resource KubernetesCluster.containerservice by adding the parameter oidcIssuerEnabled: true
  • Once the resource is created, save the status.atProvider.oidcIssuerUrl value and fill in the related parameter.
• Fill in the spec.forProvider.fleet.project parameter with "projects/<project_number>"
• For the spec.forProvider.platformVersion parameter, I created and checked a data source with Terraform, but you can use the valid value platformVersion: "1.28.0-gke.3"

After providing the tricky parameters in this way, let me share with you an example with manual intervention below:

apiVersion: containerattached.gcp.upbound.io/v1beta1
kind: Cluster
metadata:
  annotations:
    meta.upbound.io/example-id: containerattached/v1beta1/cluster
    upjet.upbound.io/manual-intervention: "This resource requires a valid issuerUrl value from the AKS or EKS cluster."
  labels:
    testing.upbound.io/example-name: primary
  name: primary
spec:
  forProvider:
    description: Test cluster
    distribution: aks
    fleet:
    - project: projects/${data.google_project.project.number}
    location: us-west1
    oidcConfig:
    - issuerUrl: https://oidc.issuer.url
    platformVersion: ${data.google_container_attached_versions.versions.valid_versions[0]}
    project: ${data.google_project.project.project_id}

[RedbackThomson]

Added manual intervention annotation to the example.

I was able to test the resource with an existing attached cluster, and saw that it was able to reconcile the status into the resource. It looks like it works 👍🏼

[turkenf]

Thank you @RedbackThomson, it seems that there are uncommitted changes after make generate, could you please run make generate and commit all changes?

And it would be great if you could add how you tested it in the PR description.

[RedbackThomson]

@turkenf Looks like it needed a rebase and regenerate. Fixed up that commit and force pushed.

Added my test methodology to the description, with an example manifest.