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

✨ Initial support for conditions for AzureMachinePool #978

Merged
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -296,8 +296,52 @@ spec:
status:
description: AzureMachinePoolStatus defines the observed state of AzureMachinePool
properties:
conditions:
description: Conditions defines current service state of the AzureMachinePool.
items:
description: Condition defines an observation of a Cluster API resource
operational state.
properties:
lastTransitionTime:
description: Last time the condition transitioned from one status
to another. This should be when the underlying condition changed.
If that is not known, then using the time when the API field
changed is acceptable.
format: date-time
type: string
message:
description: A human readable message indicating details about
the transition. This field may be empty.
type: string
reason:
description: The reason for the condition's last transition
in CamelCase. The specific API may choose whether or not this
field is considered a guaranteed API. This field may not be
empty.
type: string
severity:
description: Severity provides an explicit classification of
Reason code, so the users or machines can immediately understand
the current situation and act accordingly. The Severity field
MUST be set only when Status=False.
type: string
status:
description: Status of the condition, one of True, False, Unknown.
type: string
type:
description: Type of condition in CamelCase or in foo.example.com/CamelCase.
Many .condition.type values are consistent across resources
like Available, but because arbitrary conditions can be useful
(see .node.status.conditions), the ability to deconflict is
important.
type: string
required:
- status
- type
type: object
type: array
failureMessage:
description: "ErrorMessage will be set in the event that there is
description: "FailureMessage will be set in the event that there is
a terminal problem reconciling the MachinePool and will contain
a more verbose string suitable for logging and human consumption.
\n This field should not be set for transitive errors that a controller
Expand All @@ -313,9 +357,9 @@ spec:
output."
type: string
failureReason:
description: "ErrorReason will be set in the event that there is a
terminal problem reconciling the MachinePool and will contain a
succinct value suitable for machine interpretation. \n This field
description: "FailureReason will be set in the event that there is
a terminal problem reconciling the MachinePool and will contain
a succinct value suitable for machine interpretation. \n This field
should not be set for transitive errors that a controller faces
that are expected to be fixed automatically over time (like service
outages), but instead indicate that something is fundamentally wrong
Expand Down
19 changes: 17 additions & 2 deletions exp/api/v1alpha3/azuremachinepool_types.go
Original file line number Diff line number Diff line change
Expand Up @@ -18,6 +18,7 @@ package v1alpha3

import (
metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
clusterv1 "sigs.k8s.io/cluster-api/api/v1alpha3"
"sigs.k8s.io/cluster-api/errors"

infrav1 "sigs.k8s.io/cluster-api-provider-azure/api/v1alpha3"
Expand Down Expand Up @@ -96,7 +97,7 @@ type (
// +optional
ProvisioningState *infrav1.VMState `json:"provisioningState,omitempty"`

// ErrorReason will be set in the event that there is a terminal problem
// FailureReason will be set in the event that there is a terminal problem
// reconciling the MachinePool and will contain a succinct value suitable
// for machine interpretation.
//
Expand All @@ -115,7 +116,7 @@ type (
// +optional
FailureReason *errors.MachineStatusError `json:"failureReason,omitempty"`

// ErrorMessage will be set in the event that there is a terminal problem
// FailureMessage will be set in the event that there is a terminal problem
// reconciling the MachinePool and will contain a more verbose string suitable
// for logging and human consumption.
//
Expand All @@ -133,6 +134,10 @@ type (
// controller's output.
// +optional
FailureMessage *string `json:"failureMessage,omitempty"`

// Conditions defines current service state of the AzureMachinePool.
// +optional
Conditions clusterv1.Conditions `json:"conditions,omitempty"`
}

// +kubebuilder:object:root=true
Expand Down Expand Up @@ -165,6 +170,16 @@ type (
}
)

// GetConditions returns the list of conditions for an AzureMachinePool API object.
func (amp *AzureMachinePool) GetConditions() clusterv1.Conditions {
return amp.Status.Conditions
}

// SetConditions will set the given conditions on an AzureMachinePool object
func (amp *AzureMachinePool) SetConditions(conditions clusterv1.Conditions) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this change also include defining basic conditions for AzureMachinePools and setting them in the controller like https://github.com/kubernetes-sigs/cluster-api-provider-azure/pull/714/files#diff-825ec7ff34f98855f2347c7f7769438dR284 did?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds reasonable. I'll look into it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@nprokopic are you still planning to do this? If not, we can merge this as-is and mark the issue as incomplete

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I do, just couldn't find the time in the previous weeks.

Can we merge this and have a separate pull request for setting conditions?

Lately I was working on conditions implementation for Giant Swarm's azure-operator (where we use CAPI and CAPZ types), here's what we added for current alpha release (so not fully completed yet) for Cluster, AzureCluster and MachinePool giantswarm/azure-operator#1112, and here is current WIP for AzureMachinePool giantswarm/azure-operator#1123.
Once we wrap these up, I would take a look at what's currently done in CAPZ, and then open an issue with suggestions for conditions that would make sense for CAPZ.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay let's do that.

amp.Status.Conditions = conditions
}

func init() {
SchemeBuilder.Register(&AzureMachinePool{}, &AzureMachinePoolList{})
}
8 changes: 8 additions & 0 deletions exp/api/v1alpha3/zz_generated.deepcopy.go

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.