Tracking issue for Improving status in CAPI resources - Phase 2

[fabriziopandini]

This is a tracking issue for activities related to #10897
Phase 1 activities are tracked into #11105

Follow up from phase 1 (1.10)

• Fine tuning of godocs for API types (make them kubectl explain compliant)
  - rif 📖 Proposal: Improving status in CAPI resources #10897 (comment)
  - it seems it is address in latest version of controller-tools (see comment below)
• Extending CC to allow the definition of AvailabilityGates & ReadinessGates (and Cluster topology) ✨ Add Availability and ReadinessGates to ClusterClass #11868
  • rif 📖 Proposal: Improving status in CAPI resources #10897 (comment)
  • rif ✨ Add v1beta2 structs to object status #11234 (comment)
• Consider if to allow users to add arbitrary ReadinessGates to KCP machines ✨ Add Availability and ReadinessGates to ClusterClass #11868
• Rename test types to align to API types (v1Beta2 in the middle) 🌱 Rename v1beta2 test types #11832
• ExtensionConfig 🌱 Add v1beta2 conditions to ExtensionConfig #11848
• DockerCluster and DockerMachine controllers
• Add support for negative polarity conditions to ReadinessGates and AvailabilityGates

Looking for volunteers (like everything else MachinePools)

• MachinePool conditions
  • Implement conditions on MachinePools and MachinePool Machines (UpToDate)
  • Revert 🐛 Disable aggregation of not reported MachinePool conditions for Cluster #11416
• DockerMachinePool
  • Add v1beta2 struct
  • Paused

Backlog (if and when we have bandwidth

• Drop fake objects from controller tests and use the test/util/builders package

Dropped

• Check if NodeNetworkUnavailable must be added to MachineNodeHealthyCondition
  • Looks like NodeNetworkUnavailable is a left over of in tree gcp provider
• Allow customisation of remote-conditions-grace-period at cluster level
  • rif 📖 Proposal: Improving status in CAPI resources #10897 (comment)
• InMemoryCluster and InMemoryMachine controllers
  • It is being merged in CAPD(ev)

Implementation Phase2 (1.11)

Initial notes for phase 2 of the implementation, where new field are promoted top level in status and used by controllers

• v1beta2 API (not strictly related to this issue)
  • Prepare main branch
  • Create v1beta2 types, make controllers/webhooks to use it
    • Update example templates
  • Change clusterctl & E2E tests & test extensions to use v1beta2
  • Consider if to step up test coverage where API version is relevant (e.g. CC, topology controller, Runtime Extension)
  • Update doc about current version
• API changes for status
  • Introduce deprecated struct, move v1beta2 top level
  • Rename condition interfaces and method implementations (current--> deprecated, v1beta2--> current)
  • Rename condition consts (current--> deprecated, v1beta2--> current)
  • Move conditions fields as the first field in the struct
    • rif. 📖 Proposal: Improving status in CAPI resources #10897 (comment)
  • Add minReadySeconds to machine, remove it from KCP. MD
• Fine tuning of print columns
  • rif 📖 Proposal: Improving status in CAPI resources #10897 (review)
  • rif 📖 Proposal: Improving status in CAPI resources #10897 (comment)
• Change contracts
  • When reading from external objects, read new fields, fallback to old ones
  • Update contract docs
• Use new fields
  • (every controller that use conditions or counters)
  • MachineHealthCheck controller
    • Change test for ControlPlaneInitializedCondition in reconcile
    • Get MachineHealthCheckSucceededCondition in patchUnhealthyTargets
    • Drop failureReson/failureMessage test from needsRemediation
    • Change test for ControlPlaneInitializedCondition, InfrastructureReadyCondition in needsRemediation (few places)
  • KCP controller
    • Change test for MachineEtcdMemberHealthyCondition in canSafelyRemoveEtcdMember + add a test for ClusterHealthy if not already there
    • We should use the Initialized condition instead of the Available condition to calculate remoteConditionsGracePeriod
• Condition utils
  • Rename packages for condition utils (conditions-->deprecated conditions, v1beta2conditions --> conditions)
• Clusterctl
  • clusterctl describe (drop v1beta2 flag, introduce deprecated flag, switch default behaviour in the implementation)
• Change metrics & dashboards to use conditions

Implementation Phase3

TBD

Backlog / unprioritized

• Scale testing with CAPD (check for condition flakiness)

[sbueringer]

Assigned to v1.10 for now to keep an eye on it. I think it's not clear yet in which release this will land.

[fabriziopandini]

WRT to make new API fields kubectl explain compliant (rif #10897 (comment))

New fields introduced by the improve status proposal doesn't have fancy formatting anymore; never the less, it seems that this issue has been addressed in latest version of controller tools:

field with list using *

  template      <string>
    template defines the template to use for generating the name of the
    ControlPlane object.
    If not defined, it will fallback to `{{ .cluster.name }}-{{ .random }}`.
    If the templated string exceeds 63 characters, it will be trimmed to 58
    characters and will
    get concatenated with a random suffix of length 5.
    The templating mechanism provides the following arguments:
    * `.cluster.name`: The name of the cluster object.
    * `.random`: A random alphanumeric string, without vowels, of length 5.

field with list using -

  nodeStartupTimeout    <string>
    nodeStartupTimeout allows to set the maximum time for MachineHealthCheck
    to consider a Machine unhealthy if a corresponding Node isn't associated
    through a `Spec.ProviderID` field.

    The duration set in this field is compared to the greatest of:
    - Cluster's infrastructure ready condition timestamp (if and when available)
    - Control Plane's initialized condition timestamp (if and when available)
    - Machine's infrastructure ready condition timestamp (if and when available)
    - Machine's metadata creation timestamp

    Defaults to 10 minutes.
    If you wish to disable this feature, set the value explicitly to 0.