✨ Add v1beta2 conditions infrastructure to AWSCluster by Arpit529Srivastava · Pull Request #5854 · kubernetes-sigs/cluster-api-provider-aws

Arpit529Srivastava · 2026-01-29T21:20:56Z

What type of PR is this?
/kind api-change
/kind feature

What this PR does / why we need it:

This pr prepares AWSCluster for migrating conditions to the new metav1.Condition format, following the same explicit dual-write pattern used in CAPI.

it adds a new V1Beta2 field to AWSClusterStatus to hold the next-generation condition set alongside the existing one, and implements GetV1Beta2Conditions and SetV1Beta2Conditions on AWSCluster. the conversion logic is updated so the V1Beta2 field is preserved across version conversions (v1beta2 ↔ v1beta1).

like capi, this keeps the dual-write logic explicit rather than introducing helper abstractions. that way, deprecated v1beta1 logic stays clearly separated from the newer v1beta2+ logic, making it easier to remove the legacy path later.

the actual v1beta2 condition constants will be introduced in a follow-up pr alongside the controller changes that will consume them.

Which issue(s) this PR fixes:

related : #5835

Special notes for your reviewer:

PR only includes API/Status changes and constants. No controller logic is changed in this PR. The controller implementation (dual-writing) will be handled in a follow-up PR.
Checklist:

Release note:

 Added v1beta2 conditions infrastructure (Status field and Constants) to `AWSCluster` to support future migration.

Signed-off-by: arpit529srivastava <arpitsrivastava529@gmail.com>

k8s-ci-robot · 2026-01-29T21:21:06Z

Hi @Arpit529Srivastava. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

nrb · 2026-01-29T21:30:56Z

/ok-to-test

Signed-off-by: arpit529srivastava <arpitsrivastava529@gmail.com>

Arpit529Srivastava · 2026-02-04T11:19:50Z

@damdo a gentle ping, thanks :)

damdo

Hey @Arpit529Srivastava thanks a lot for your PR!
This is a good start :)

Left some comments

damdo · 2026-02-04T11:30:21Z

api/v1beta1/awscluster_conversion.go

@@ -150,6 +150,9 @@ func (src *AWSCluster) ConvertTo(dstRaw conversion.Hub) error {
 		}


I don't think we should touch v1beta1 types at all.
Only v1beta2 ones

@damdo just to make sure i’m understanding correctly about the v1beta1 conversion changes, should i remove the V1Beta3 restoration logic from awscluster_conversion.go? i followed the same pattern used for existing fields like ControlPlaneLoadBalancer, but i’m totally fine removing it if that’s not the direction we want to take.
wanted to confirm this part before i move on to the rest of the feedback. thanks

As we are adding new fields in v1beta2 then we need to preserve roundtrip compatibility. So it will require that you update the conversions in v1beta1 like you have done here to restore the value.

A lot of people make the mistake of adding the new field to old api versions as well to make the conversions work. But restoring the value from the saved state is the correct way (like you are doing).

As we are adding new fields in v1beta2 then we need to preserve roundtrip compatibility. So it will require that you update the conversions in v1beta1 like you have done here to restore the value.

Good point! Hadn't thought about that!

damdo · 2026-02-04T11:31:21Z

api/v1beta2/awscluster_types.go

+// AWSClusterV1Beta3Status groups all the fields that will be added or modified in AWSClusterStatus with the V1Beta3 version.
+// See https://github.com/kubernetes-sigs/cluster-api/blob/main/docs/proposals/20240916-improve-status-in-CAPI-resources.md for more context.
+type AWSClusterV1Beta3Status struct {
+	// conditions represents the observations of an AWSCluster's current state.


Suggested change

// conditions represents the observations of an AWSCluster's current state.

// Conditions represents the observations of an AWSCluster's current state.

damdo · 2026-02-04T11:36:31Z

api/v1beta2/conditions_consts.go

 	DedicatedHostReleaseFailedReason = "DedicatedHostReleaseFailed"
 )
+
+// AWSCluster's v1beta2 conditions and corresponding reasons.


Suggested change

// AWSCluster's v1beta2 conditions and corresponding reasons.

// AWSCluster's v1beta3 conditions and corresponding reasons.

damdo · 2026-02-04T11:40:11Z

api/v1beta2/conditions_consts.go

 	DedicatedHostReleaseFailedReason = "DedicatedHostReleaseFailed"
 )
+
+// AWSCluster's v1beta2 conditions and corresponding reasons.


Also we should probably move these to a different place, how are other CAPI providers doing this during their transition?

i took another look and separating them does seem like the cleaner approach. i’ll move the new v1beta3 constants into a separate file (api/v1beta2/conditions_consts_v1beta3.go).

damdo · 2026-02-04T12:58:02Z

api/v1beta2/conditions_consts.go

 )
+
+// AWSCluster's v1beta2 conditions and corresponding reasons.
+// These will be used with the V1Beta2 API version.


Will be or, are for CAPA v1beta2?

damdo · 2026-02-04T12:58:08Z

api/v1beta2/conditions_consts.go

+// AWSCluster's v1beta2 conditions and corresponding reasons.
+// These will be used with the V1Beta2 API version.
+
+// AWSCluster's Ready condition and corresponding reasons that will be used in v1Beta2 API version.


damdo · 2026-02-04T12:59:34Z

api/v1beta2/awscluster_types.go

+	// +listType=map
+	// +listMapKey=type
+	// +kubebuilder:validation:MaxItems=32
+	Conditions []metav1.Condition `json:"conditions,omitempty"`


Are we only dealing with AWSCluster and Conditions here?
If we do it this granular we'll potentially end up with (number of API types) x (number of fields to add) PRs

my bad, i was initially planning to split these into separate prs to keep things smaller,. i agree it’s better to avoid creating too many prs for closely related changes.

rethinking again, once we settle on the approach for v1beta1 conversions, #5854 (comment) i’ll add the same V1Beta3 status field to the other types as well (AWSMachine, AWSMachinePool, AWSManagedMachinePool, etc ...) in this same pr. just wanted to make sure we’re aligned on the pattern with AWSCluster first before rolling it out everywhere.

I'm happy either way. Smaller PRs always helps with review though.

Arpit529Srivastava · 2026-02-04T19:24:33Z

Hey @Arpit529Srivastava thanks a lot for your PR!
This is a good start :)

Left some comments

thanks for the review 😃, taking a look.

damdo · 2026-02-04T21:07:53Z

/assign @nrb @damdo @richardcase @clebs

Signed-off-by: arpit529srivastava <arpitsrivastava529@gmail.com>

k8s-ci-robot · 2026-02-05T10:22:54Z

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please ask for approval from damdo. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

Arpit529Srivastava · 2026-02-10T10:36:06Z

@clebs, can you please take a look.
Thanks

clebs · 2026-02-10T10:44:28Z

api/v1beta2/conditions_consts_v1beta3.go

@@ -0,0 +1,114 @@
+/*


Why are these constants introduced? They are not being used anywhere and most values are duplicating existing constants.

hmm, make sense.. i initially added these constants as groundwork for the next step, where the AWSClusterController will dual-write conditions into both status.conditions and status.v1beta3.conditions. however, rightg now since nothing in this pr actually consumes them yet, ill remove them.

will introduce them together with the controller changes in the follow-up pr where they’ll actually be used.

Great thanks! Makes sense to introduce them in the next step. Also only introducing what is necessary.

also @clebs, could you please advise me on this comment? I’m a little stuck here. Thanks, I really appreciate your help.

Looking at the initial comment from @damdo, he is saying you should not update files under api/v1beta1. Only files under api/v1beta2.

The comment is not asking to change CAPI conversion, just to not include it in the older CAPA v1beta1 API.

Please bear in mind that CAPI v1beta1 and CAPA v1beta1 are 2 different things.

thanks @clebs for the review will keep this in mind.

Signed-off-by: arpit529srivastava <arpitsrivastava529@gmail.com>

richardcase · 2026-02-11T16:29:28Z

api/v1beta1/awscluster_conversion.go

@@ -150,6 +150,9 @@ func (src *AWSCluster) ConvertTo(dstRaw conversion.Hub) error {
 		}


As we are adding new fields in v1beta2 then we need to preserve roundtrip compatibility. So it will require that you update the conversions in v1beta1 like you have done here to restore the value.

richardcase · 2026-02-11T16:31:04Z

api/v1beta1/awscluster_conversion.go

@@ -150,6 +150,9 @@ func (src *AWSCluster) ConvertTo(dstRaw conversion.Hub) error {
 		}


A lot of people make the mistake of adding the new field to old api versions as well to make the conversions work. But restoring the value from the saved state is the correct way (like you are doing).

richardcase · 2026-02-11T16:31:57Z

api/v1beta2/awscluster_types.go

+	// +listType=map
+	// +listMapKey=type
+	// +kubebuilder:validation:MaxItems=32
+	Conditions []metav1.Condition `json:"conditions,omitempty"`


I'm happy either way. Smaller PRs always helps with review though.

richardcase · 2026-02-11T16:36:37Z

api/v1beta2/awscluster_types.go

 }

+// GetV1Beta3Conditions returns the set of conditions for this object.
+func (r *AWSCluster) GetV1Beta3Conditions() []metav1.Condition {


This is where the naming of things is going to get weird 😉

We need to adopt paused.EnsurePausedCondition in our controllers. This means that AWSCluster (and our other resource types) need to implement the v1beta2conditions.Setter/Getter interfaces . So these methods need to be named:

// SetV1Beta2Conditions sets conditions for an API object. // Note: SetV1Beta2Conditions will be renamed to SetConditions in a later stage of the transition to V1Beta2. SetV1Beta2Conditions([]metav1.Condition) // GetV1Beta2Conditions returns the list of conditions for a cluster API object. // Note: GetV1Beta2Conditions will be renamed to GetConditions in a later stage of the transition to V1Beta2. GetV1Beta2Conditions() []metav1.Condition

Or we need additional functions.

It will be very messy/weird until we drop the old fields.

thanks for clarifying 😄
i’ve updated the implementation to use GetV1Beta2Conditions() and SetV1Beta2Conditions() along with the Note: comments you mentioned.

it does feel a bit awkward during the transition, but i agree it’s better to align exactly with capi’s interface expectations.

Signed-off-by: arpit529srivastava <arpitsrivastava529@gmail.com>

Arpit529Srivastava · 2026-02-11T20:07:16Z

@richardcase @damdo made all corrections, PTAL .
thanks :)

richardcase

Looking good @Arpit529Srivastava . I made some suggestions around the comments to make it obvious that we are talking about "CAPI contract" v1beta2 and not CAPA v1beta2.

Would you now plan to add the same changes for the other resource kinds?

richardcase · 2026-02-12T09:06:59Z

api/v1beta2/awscluster_types.go

+	V1Beta2 *AWSClusterV1Beta2Status `json:"v1beta2,omitempty"`
+}
+
+// AWSClusterV1Beta2Status groups all the fields that will be added or modified in AWSCluster with the V1Beta2 version.


Suggested change

// AWSClusterV1Beta2Status groups all the fields that will be added or modified in AWSCluster with the V1Beta2 version.

// AWSClusterV1Beta2Status groups all the fields that will be added or modified in AWSCluster with the V1Beta2 CAPI contract version.

richardcase · 2026-02-12T09:07:23Z

api/v1beta2/awscluster_types.go

 	Bastion        *Instance                     `json:"bastion,omitempty"`
 	Conditions     clusterv1beta1.Conditions     `json:"conditions,omitempty"`
+
+	// v1beta2 groups all the fields that will be added or modified in AWSCluster's status with the V1Beta2 version.


Suggested change

// v1beta2 groups all the fields that will be added or modified in AWSCluster's status with the V1Beta2 version.

// v1beta2 groups all the fields that will be added or modified in AWSCluster's status with the V1Beta2 CAPI contract version.

richardcase · 2026-02-12T09:07:58Z

api/v1beta2/awscluster_types.go

 }

+// GetV1Beta2Conditions returns the set of conditions for this object.
+// Note: GetV1Beta2Conditions will be renamed to GetConditions in a later stage of the transition to V1Beta2.


Suggested change

// Note: GetV1Beta2Conditions will be renamed to GetConditions in a later stage of the transition to V1Beta2.

// Note: GetV1Beta2Conditions will be renamed to GetConditions in a later stage of the transition to CAPI contract V1Beta2.

richardcase · 2026-02-12T09:08:18Z

api/v1beta2/awscluster_types.go

+}
+
+// SetV1Beta2Conditions sets conditions for an API object.
+// Note: SetV1Beta2Conditions will be renamed to SetConditions in a later stage of the transition to V1Beta2.


Suggested change

// Note: SetV1Beta2Conditions will be renamed to SetConditions in a later stage of the transition to V1Beta2.

// Note: SetV1Beta2Conditions will be renamed to SetConditions in a later stage of the transition to CAP contract V1Beta2.

Signed-off-by: arpit529srivastava <arpitsrivastava529@gmail.com>

Arpit529Srivastava · 2026-02-12T14:59:25Z

Looking good @Arpit529Srivastava . I made some suggestions around the comments to make it obvious that we are talking about "CAPI contract" v1beta2 and not CAPA v1beta2.

Would you now plan to add the same changes for the other resource kinds?

for the other resource kinds - yes, i’m planning to add them as well. since you mentioned that smaller prs are easier to review, i started with AWSCluster first and will follow up with separate prs for the remaining types.

is there anything specific i should watch out for when applying the same pattern to the other resources? any heads-up before i proceed?
thanks for reviewing :)

richardcase · 2026-02-12T15:06:42Z

@Arpit529Srivastava - it might be nice to add a task list to #5835 so that progress can be tracked and people can help out. Once the conditions are added to the types, i'm guessing that the next stage is to then dual right conditions to the new fields?

Arpit529Srivastava · 2026-02-12T15:17:17Z

sure that is much better way, added a task list to #5835 for tracking. thanks
if everything looks good, we can proceed with merging. awaiting your review. :)

Add v1beta2 conditions infrastructure to AWSCluster

0a79592

Signed-off-by: arpit529srivastava <arpitsrivastava529@gmail.com>

k8s-ci-robot requested review from AndiDog and damdo January 29, 2026 21:21

k8s-ci-robot added size/L Denotes a PR that changes 100-499 lines, ignoring generated files. needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. labels Jan 29, 2026

k8s-ci-robot added ok-to-test Indicates a non-member PR verified by an org member that is safe to test. and removed needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. labels Jan 29, 2026

Arpit529Srivastava added 2 commits January 30, 2026 03:09

fix: remove comment separators to satisfy godot linter

2dc7df7

Signed-off-by: arpit529srivastava <arpitsrivastava529@gmail.com>

fix: rename v1beta2 conditions field to v1beta3 and fix conversion

4eb8d9e

Signed-off-by: arpit529srivastava <arpitsrivastava529@gmail.com>

damdo reviewed Feb 4, 2026

View reviewed changes

k8s-ci-robot assigned clebs, damdo, nrb and richardcase Feb 4, 2026

fix: reorganize v1beta3 conditions and update comments

48182c1

Signed-off-by: arpit529srivastava <arpitsrivastava529@gmail.com>

Arpit529Srivastava requested a review from damdo February 5, 2026 11:27

clebs reviewed Feb 10, 2026

View reviewed changes

remove unused v1beta3 condition constants

ad57c6a

Signed-off-by: arpit529srivastava <arpitsrivastava529@gmail.com>

Arpit529Srivastava requested a review from clebs February 10, 2026 11:39

richardcase requested changes Feb 11, 2026

View reviewed changes

fix: align AWSCluster status with v1beta2

44772a3

Signed-off-by: arpit529srivastava <arpitsrivastava529@gmail.com>

Arpit529Srivastava requested a review from richardcase February 11, 2026 20:06

richardcase reviewed Feb 12, 2026

View reviewed changes

add CAPI contract clarification to V1Beta2 comments

b97102d

Signed-off-by: arpit529srivastava <arpitsrivastava529@gmail.com>

Arpit529Srivastava mentioned this pull request Feb 12, 2026

Upgrade to remaining v1beta2 CAPI types #5835

Open

Arpit529Srivastava requested a review from richardcase February 12, 2026 15:24

		@@ -150,6 +150,9 @@ func (src *AWSCluster) ConvertTo(dstRaw conversion.Hub) error {
		}

	// conditions represents the observations of an AWSCluster's current state.
	// Conditions represents the observations of an AWSCluster's current state.

	// AWSCluster's v1beta2 conditions and corresponding reasons.
	// AWSCluster's v1beta3 conditions and corresponding reasons.

	// AWSClusterV1Beta2Status groups all the fields that will be added or modified in AWSCluster with the V1Beta2 version.
	// AWSClusterV1Beta2Status groups all the fields that will be added or modified in AWSCluster with the V1Beta2 CAPI contract version.

	// v1beta2 groups all the fields that will be added or modified in AWSCluster's status with the V1Beta2 version.
	// v1beta2 groups all the fields that will be added or modified in AWSCluster's status with the V1Beta2 CAPI contract version.

	// Note: GetV1Beta2Conditions will be renamed to GetConditions in a later stage of the transition to V1Beta2.
	// Note: GetV1Beta2Conditions will be renamed to GetConditions in a later stage of the transition to CAPI contract V1Beta2.

	// Note: SetV1Beta2Conditions will be renamed to SetConditions in a later stage of the transition to V1Beta2.
	// Note: SetV1Beta2Conditions will be renamed to SetConditions in a later stage of the transition to CAP contract V1Beta2.

Conversation

Arpit529Srivastava commented Jan 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

k8s-ci-robot commented Jan 29, 2026

Uh oh!

nrb commented Jan 29, 2026

Uh oh!

Arpit529Srivastava commented Feb 4, 2026

Uh oh!

damdo left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Arpit529Srivastava Feb 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Arpit529Srivastava commented Feb 4, 2026

Uh oh!

damdo commented Feb 4, 2026

Uh oh!

k8s-ci-robot commented Feb 5, 2026

Uh oh!

Arpit529Srivastava commented Feb 10, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Arpit529Srivastava Feb 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Arpit529Srivastava commented Feb 11, 2026

Arpit529Srivastava commented Jan 29, 2026 •

edited

Loading

Arpit529Srivastava Feb 5, 2026 •

edited

Loading

Arpit529Srivastava Feb 10, 2026 •

edited

Loading

Arpit529Srivastava commented Feb 12, 2026 •

edited

Loading