For those who attended the SIG face to face during the KubeCon contributor summit, we went around the room and asked if there was one and only one feature you could get in the next release, what would it be. For reference, here is that list:
- Remote node ref
- Health Status
- Better error reporting.
- Dedicated api group for worker machines
- Decoupling bootstrapping config from provider implementation
- Default test-bed using something like (kind)
- There already exists in repo as the example provider.
- Or possibly libvirt
- Cluster Required
- Cluster Optional
- Optionally vs. required fields
- E.g. cluster reference on machine/node object.
- Orchestrating upgrades.
At this week’s Cluster API meeting, I proposed that we decrease the scope of v1alpha2 from “anything and everything” () to something smaller and more tangible. Additionally, we should strive to have multiple, frequent, iterative releases, which is aligned with yesterday’s release cadence proposal.I’d like to propose that we focus on “Decoupling bootstrapping config from provider implementation” along with an initial formalization and realization of machine states (what the node lifecycle workstream was working on - https://docs.google.com/document/d/14Ec1aKjFtbhrGykLHtw8uPXa4TPtKIR2QiNbXArLVuI/edit#heading=h.c0njve9f8kbn).
It seems like decoupling bootstrapping from machine infrastructure is a good first step that can open up a lot of possibilities going forward. Once this is implemented, we can work on creating a component to manage the control plane lifecycle, leveraging the bootstrapping/infrastructure separation work as a foundation. We can also use the bootstrapping work to help with upgrades.
Some of us spent some time at a whiteboard at KubeCon working through a possible design for the bootstrap/infrastructure separation. We’d like to present a draft proposal early next week and hope to get buy-in from the community.
How does everyone feel about focusing on the bootstrapping work as the one major feature of v1alpha2?