Align Object readiness to Manifest readiness

[braghettos]

What problem are you facing?

One of the actual limitations of Crossplane is that existing Kubernetes operator (i.e. check operatorhub.io) cannot be integrated within a Composition because the provider-kubernetes - in particular, the Kind Object - is not aware of the Readiness of the applied manifest. The actual implementation of Kind Object has status Ready when the Kubernetes manifest is applied.

How could Crossplane help solve your problem?

The Ready status of the Kind Object should be aligned with the status of the applied Manifest. This would expand the compatibility of the Composition with operators that are not implement with the Crossplane runtime.

[bobh66]

Can you provide a specific example of what you're trying to do and how the provider can facilitate it?

[braghettos]

I.e. with ClusterAPI I have the following Custom Resource:

apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"cluster.x-k8s.io/v1beta1","kind":"Cluster","metadata":{"annotations":{},"name":"kgcp","namespace":"default"},"spec":{"clusterNetwork":{"pods":{"cidrBlocks":["192.168.0.0/16"]},"serviceDomain":"cluster.local"},"controlPlaneRef":{"apiVersion":"controlplane.cluster.x-k8s.io/v1beta1","kind":"KubeadmControlPlane","name":"kgcp-control-plane"},"infrastructureRef":{"apiVersion":"infrastructure.cluster.x-k8s.io/v1alpha5","kind":"OpenStackCluster","name":"kgcp"}}}
  creationTimestamp: "2022-10-04T10:12:07Z"
  finalizers:
  - cluster.cluster.x-k8s.io
  generation: 2
  name: kgcp
  namespace: default
  resourceVersion: "14411953"
  uid: 85e8b8c0-a9bb-4c7e-9c60-4ede559b625b
spec:
  clusterNetwork:
    pods:
      cidrBlocks:
      - 192.168.0.0/16
    serviceDomain: cluster.local
  controlPlaneEndpoint:
    host: 10.154.16.48
    port: 6443
  controlPlaneRef:
    apiVersion: controlplane.cluster.x-k8s.io/v1beta1
    kind: KubeadmControlPlane
    name: kgcp-control-plane
    namespace: default
  infrastructureRef:
    apiVersion: infrastructure.cluster.x-k8s.io/v1alpha5
    kind: OpenStackCluster
    name: kgcp
    namespace: default
status:
  conditions:
  - lastTransitionTime: "2022-10-04T10:14:06Z"
    status: "True"
    type: Ready
  - lastTransitionTime: "2022-10-04T10:14:06Z"
    status: "True"
    type: ControlPlaneInitialized
  - lastTransitionTime: "2022-10-04T10:14:06Z"
    status: "True"
    type: ControlPlaneReady
  - lastTransitionTime: "2022-10-04T10:12:33Z"
    status: "True"
    type: InfrastructureReady
  controlPlaneReady: true
  failureDomains:
    az1:
      controlPlane: true
    az2:
      controlPlane: true
    nova:
      controlPlane: true
  failureMessage: 'Failure detected from referenced resource infrastructure.cluster.x-k8s.io/v1alpha5,
    Kind=OpenStackCluster with name "kgcp": failed to reconcile external network:
    found 2 external networks, which should not happen'
  failureReason: UpdateError
  infrastructureReady: true
  observedGeneration: 2
  phase: Failed

I would like to kind Object to be Ready when the CR has the status.controlPlaneReady: true

[blakebarnett]

I might be misunderstanding, but I think you can use the readiness string matching to map the status.atProvider field of your choice for a check? https://crossplane.io/docs/v1.9/reference/composition.html#readiness-checks

[braghettos]

@blakebarnett the status.atProvider of the Kind Object is mapped to the status of the applied manifest via that Object?

[bobh66]

status.atProvider.manifest contains a full copy of the associated kubernetes resource so you can see exactly what it looks like and reference all of the spec/status/etc fields and you can create Composition readiness checks like this:

    readinessChecks:
      - type: MatchString
        fieldPath: status.atProvider.manifest.status.ready
        matchString: "True"

so that the composed resource readiness status matches that of the wrapped kubernetes Object.

The Object readiness status is associated with that of the provider - did the provider create the resource that the Object represents successfully. That needs to be tracked separately from the status of the wrapped object so that it is possible/easy to debug issues with the kubernetes provider.

[braghettos]

@bobh66 thank you for the feedback! It wasn't clear in the documentation IMHO.