Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add conditions to the KubeadmConfig object #3110

Closed
fabriziopandini opened this issue May 28, 2020 · 3 comments · Fixed by #3125
Closed

Add conditions to the KubeadmConfig object #3110

fabriziopandini opened this issue May 28, 2020 · 3 comments · Fixed by #3125
Assignees
Labels
kind/feature Categorizes issue or PR as related to a new feature. lifecycle/active Indicates that an issue or PR is actively being worked on by a contributor.
Milestone

Comments

@fabriziopandini
Copy link
Member

fabriziopandini commented May 28, 2020

User Story

As a developer/user/operator I would like to have conditions documenting the operational state of KubeadmConfig objects

Detailed Description

The KubeadmConfig object drives the process of generating a BootstrapSecret; this process waits for the cluster infrastructure to be ready first and then the KubeadmConfig for first control plane machine is processed; instead, the KubeadmConfig objects for additional control plane nodes and the KubeadmConfig for workers should wait for that the first control plane machine to be initialized before being processed.
Once a BootstrapSecret secret is generated, no further actions are taken for a KubeadmConfig.

As a consequence, I'm proposing to implement a single condition for the KubeadmConfig object

// DataSecretGeneratedCondition provides an observation of the bootstrap secret generation process.
// The condition gets generated at the first reconciliation.
DataSecretGeneratedCondition clusterv1.ConditionType = "DataSecretGenerated"

State=True represents a properly generated BootstrapSecret, while State=False represents the process of waiting for the preconditions for generating the BootstrapSecret and this phase can be further detailed by the following reasons:

// WaitingForClusterInfrastructure (Severity=Info) reason documents a bootstrap secret generation process waiting for the
// cluster infrastructure to be ready.
WaitingForClusterInfrastructure = "WaitingForClusterInfrastructure"

// WaitingForControlPlaneInitialized (Severity=Info) reason documents  a bootstrap secret generation process waiting for the
// first control plane machine to be ready.
WaitingForControlPlaneInitialized = "WaitingForControlPlaneInitialized"

When the BootstrapSecret generation starts the process completes immediately and within the same reconciliation, so the user will always see a transition from Wait to Succeed without having evidence that BootstrapSecret generation is started.

TBD if to add a reason Severity=Warning or Error to surface problems during this operation.

TBD if to add additional conditions reporting if/when certificates are generated; this condition applies only to the fist control plane machine when certificates are not provided by the users

Anything else you would like to add:

As required by the condition CAEP, the KubeadmConfig objects should provide a Ready condition describing the overall state of the object. However, given that the KubeadmConfig has only a condition I see two options here:
A) have a Ready condition mirroring exactly the BootstrapSecretGenerationSucceeded condition
B) have only the Ready condition that acts as the BootstrapSecretGenerationSucceeded described above

I would like to have more opinions here.

/kind feature

@k8s-ci-robot k8s-ci-robot added the kind/feature Categorizes issue or PR as related to a new feature. label May 28, 2020
@vincepri
Copy link
Member

/milestone v0.3.x

@k8s-ci-robot k8s-ci-robot added this to the v0.3.x milestone May 29, 2020
@vincepri
Copy link
Member

+1 to surface errors and exposing a generic condition when certs are generated, we should do the same in KCP later.

@fabriziopandini
Copy link
Member Author

/assign
/lifecycle active

@k8s-ci-robot k8s-ci-robot added the lifecycle/active Indicates that an issue or PR is actively being worked on by a contributor. label Jun 1, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Categorizes issue or PR as related to a new feature. lifecycle/active Indicates that an issue or PR is actively being worked on by a contributor.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants