# Cluster API: Validating label and annotation propagation ## Labels and annotations that are set by users The following labels and annotations could be set by users via ClusterClass or Cluster topology, and then they will propagate through the entire hierarchy. I think we can only implement something for the newly introduced hold-upgrade-sequence and defer-upgrade annotations in v1beta1. Everything else would be a breaking change as we consider labels and annotations part of our API. * labels: * cluster.x-k8s.io/watch-filter: is only supposed to be set top-level * => Proposal: no filtering * annotations: * topology.cluster.x-k8s.io/hold-upgrade-sequence & topology.cluster.x-k8s.io/defer-upgrade * => Proposal: do not propagate at all, seems bad to leak them over the entire hierarchy if we consider them just "experimental fields". Also requires a lot of API calls to propagate them across the entire hierarchy when they are set. * => PR is open: https://github.com/kubernetes-sigs/cluster-api/pull/8261 * autoscaler annotations * => Proposal: no filtering, we only need them at MD & MS, but I don't think we want specific handling for them * cluster.x-k8s.io/paused * => Proposal: no filtering in Cluster topology, I assume they are usually set directly on the objects by users * => What about propagation from MD.annotations=>MS.annotations? paused label is not propagated as MD controller returns early once the MD is paused. ## Labels and annotations set by Cluster API Labels and annotations set on object hierarchies: * labels: * Set on all objects * cluster.x-k8s.io/cluster-name * topology.cluster.x-k8s.io/owned * Set on MachineDeployment & below (MachineDeployment, InfraMachineTemplate, BootstrapConfigTemplate, MachineSet, Machine, BootstrapConfig, InfraMachine) * topology.cluster.x-k8s.io/deployment-name * Set below MachineDeployment (MachineSet, Machine, BootstrapConfig, InfraMachine) * cluster.x-k8s.io/deployment-name * machine-template-hash * Set below MachineSet (Machine, BootstrapConfig, InfraMachine) * cluster.x-k8s.io/set-name * Set below KCP (Machine, BootstrapConfig, InfraMachine) * cluster.x-k8s.io/control-plane * cluster.x-k8s.io/control-plane-name Others: * annotations: * MachineDeployment top level annotations are propagated but some are filtered out: * machinedeployment.clusters.x-k8s.io/revision (MachineDeployment, MachineSet) * MS top level annotations do not propagate at all: * cluster.x-k8s.io/disable-machine-create (MachineSet) * machinedeployment.clusters.x-k8s.io/revision-history (MachineSet) * machinedeployment.clusters.x-k8s.io/desired-replicas (MachineSet) * machinedeployment.clusters.x-k8s.io/max-replicas (MachineSet) * machinedeployment.clusters.x-k8s.io/revision (MachineDeployment, MachineSet) * Machine top level annotations do not propagate at all: * cluster.x-k8s.io/delete-machine (Machine) * cluster.x-k8s.io/skip-remediation (Machine) * machine.cluster.x-k8s.io/exclude-node-draining (Machine) * machine.cluster.x-k8s.io/exclude-wait-for-node-volume-detach (Machine) * pre-drain.delete.hook.machine.cluster.x-k8s.io (Machine) * pre-terminate.delete.hook.machine.cluster.x-k8s.io (Machine) * machine.cluster.x-k8s.io/certificates-expiry (Machine, BootstrapConfig) * BootstrapConfig top level annotations do not propagate at all: * machine.cluster.x-k8s.io/certificates-expiry (Machine, BootstrapConfig) * Only set on Nodes * cluster.x-k8s.io/cluster-name * cluster.x-k8s.io/cluster-namespace * Only set on top-level annotations, but in those cases not propagated anywhere * cluster.x-k8s.io/cloned-from-groupkind * cluster.x-k8s.io/cloned-from-name
Last changed by  
 
Stefan Büringer
86

Read more

Cluster API: label propagation: debugging Telekom issue

What we know T0: After Machine create + subsequent reconcile which migrates managed fieldsMachineSetan annotation in .spec.template.metadata.annotations (this is continuously reconciled) VSphereMachineTemplate annotations in .spec.template.metadata.annotations (this is only added on create) VSphereMachine Object metadata annotationsannotation from MachineSet

5/2/2023
Cluster API: v1.4 Test failures in e2e tests

High priority - Low priority Rate limit for github api has been reached Let's ignore for now, known root cause and its not our code Fails because of rate limiting when downloading cert-manager.yaml. Found in: (multiple times)e2e-main: https://prow.k8s.io/view/gs/kubernetes-jenkins/logs/periodic-cluster-api-e2e-main/1625685968952496128When testing clusterctl upgrades (v0.4=>current) Also in other test cases

3/22/2023
ClusterAPI - ClusterClass struct names (hack session)

spec: variables: # []ClusterClassVariable - name: clusterIdentityName required: true schema: # VariableSchema openAPIV3Schema: # JSONSchemaProps type: string default: cluster-identity patches: # []ClusterClassPatch - name: clusterName

1/11/2022
ClusterAPI - Running e2e tests & controllers locally with Intellij

This document contains some additional notes for the corresponding Zoom session (link Passcode: N20+nkQ%). Overall we will: Run the CAPD-based quickstart e2e test via Intellij Run the capi-controller via Intellij and proxy webhook requests from the kind cluster to the locally running controller Note: There is already documentation about how to run e2e tests via an IDE in the CAPI book. The current doc is a concrete walkthrough and additionally contains instructions on how to run a controller locally.

10/22/2021
Read more from Stefan Büringer
Published on HackMD