v1 roadmap

[CecileRobertMichon]

What should we work on for the next quarter? Now that v1beta1 / v1.0.0 is behind us, let's start thinking about what we should tackle next. Please share links to issues below and upvote the others that you would like to see in the next releases! No breaking API changes, everything else is fair game.

Note: let's keep this discussion thread limited to issue links only, and discuss each issue individually in the issue's comment thread if needed.

[fabriziopandini]

Cluster API Runtime Extensions:

goal:
To provide generic extension mechanism for CAPI that can be used when:

• The interaction between CAPI and the extension components requires synchronous/blocking RPC calls.
• Given RPC call will be synchronous/blocking, and also probably adding latency, the request could be processed in a very short time.

use cases

• external patches for ClusterClass
• lifecycle hooks
• pluggable machine/node bootrstrappers
• pluggable, provider specific defaulting/validation web hooks (e.g for Cluster.spec.Network)
• more

Issue with detailed description: #5175

[fabriziopandini]

Already implemented 🥳

[fabriziopandini]

Comprehensive solution for Cluster addons lifecycle in Cluster API

goal:
There is a set of addons that have a lifecycle strictly linked to the cluster lifecycle managed by CAPI; Current answer for this problem space is CustomResourceSets, but this covers only first installation and not the addon lifecycle / in sync with the Cluster lifecycle; the problem is getting even more urgent now that the number and the needs of Cluster addons are growing due to CSI/CPI plugins being moved out of three.

On top of that, most users have their own solution for addon management, and we should consider if/how to integrate with those solutions too

We are not seeking to reinvent an addon management solution with this issue, but instead we should focus on finding a way to lifecycle manage addons within the context of CAPI Cluster lifecycle

use cases

• CPI
• CSI
• CNI (?)
• Autoscaler (?)

Issue with detailed description: #5491

[fabriziopandini]

Already implemented 🥳

[fabriziopandini]

Improve certificate management in Cluster API

goal:
As of today Cluster API provide a minimal support for certificate management, give that the responsibility of creating certificates has been delegated to control plane providers.

While this approach worked well, some shortcomings are starting to surface, mostly boiling up to the fact that there is no top level certificate management primitives in our API, and this makes it difficult and fragmented for the users.

This issue is about starting an effort for rethinking this area, and providing a clean solution for the two issues that mostly concern users, that are better support for certificate renewal and CA rotation tasks

use cases

• customise certificate at provisioning time
• monitor state of my certificates (expiration date)
• service certificate renewal
• certificate authority rotation
• provide support for integrating with external tools for certificate management, like e.g Hashicorp Vault.

Issue with detailed description: #5490

[fabriziopandini]

tracked in #7443

[killianmuldoon]

Separate responsibilities in Kubeadm Bootstrap

goal:
Today CAPBK involves two major components / actions - machine bootstrapping (done by cloud-init) and kubernetes boostrapping (done by kubeadm). The configurations for these components, and their set up cycles, are interlinked in a way that makes it difficult to introduce new features (e.g. ignition-based bootstrapping) without needing to write a full bootstrap provider, or to change the flow of the bootstrapping process.

This issue is about refactoring the Kubeadm Bootstrap provider to provide a cleaner separation of responsibilities.

use cases

• address security concerns with the bootstrapping process
• enable developers to introduce additional machine bootstrapping providers ( as alternatives to cloud-init)

Issue with detailed description: #5294

[fabriziopandini]

tracked in #5294

[enxebre]

Support syncing a set of labels from scalable resources to Nodes

Goal:
Labels on worker nodes are commonly used for node role assignment and workload placement.
This is to add the capability to propagate a restricted set of labels/(taints?) defined in scalable resources into new nodes.

Use cases:

• As a cluster admin/user, I would like a declarative and secure means by which to assign roles to my nodes. For example, when I do kubectl get nodes, I want the ROLES column to list my assigned roles for the nodes.

• As a cluster admin/user, for the purpose of workload placement, I would like a declarative and secure means by which I can add/remove labels on groups of nodes. For example, I want to run my outward facing nginx pods on a specific set of nodes (e.g. md-secure-zone) to reduce exposure to the company's publicly trusted server certificates.

Issue with detailed description: #493

[fabriziopandini]

Already implemented 🥳

[yastij]

enable setting failureDomain as part of a cluster's topology

Goal:
Today we don't offer users the ability to configure failureDomain for the various machineDeployment that is part of a ClusterClass which limits a bit the re-usability. This is to expose the ability to configure failure domain in a managed cluster.

Use cases:

• As a user would like to configure the failure domain of workers in a managed cluster , to be able to re-use ClusterClass

Issue with detailed description: #5636

[fabriziopandini]

This has been already implemented

[dtzar]

What's the desire for CAPI roadmap? This discussion is linked on the public book.
Clearly the discussion here is dated and IMO doesn't really give users a roadmap.

I would suggest removing the link to the roadmap on the book or updating.

[CecileRobertMichon]

+1 for removing reference from the book

this discussion was meant to be used as brainstorming for v1.1.0, not as an ongoing roadmap reference

[fabriziopandini]

+1, opened #8451 to fix it

[sbueringer]

+1

[fabriziopandini]

Done

[fabriziopandini]

Closing because the discussion here isn't getting traction
Most of the items are already implemented
For the other we have tracking issue