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

fix: add member conditions in status of KonnectGatewayControlPlane #138

Draft
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

randmonkey
Copy link
Contributor

What this PR does / why we need it:

Add status.members for conditions of members in the control plane group.

Which issue this PR fixes

Part of Kong/gateway-operator#797

Special notes for your reviewer:

PR Readiness Checklist:

Complete these before marking the PR as ready to review:

  • the CHANGELOG.md release notes have been updated to reflect significant changes

@randmonkey randmonkey self-assigned this Oct 28, 2024
@randmonkey randmonkey requested a review from a team as a code owner October 28, 2024 08:57
@@ -88,6 +93,18 @@ func (c *KonnectGatewayControlPlane) GetKonnectAPIAuthConfigurationRef() Konnect
return c.Spec.KonnectConfiguration.APIAuthConfigurationRef
}

// SetMemberStatus sets conditions of a member of the control plane group in status.
// REVIEW: is it better to replace it with `SetMemberCondition` to set a single condition of a member?
Copy link
Member

Choose a reason for hiding this comment

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

Do we see a use case for setting more than 1 condition for a member?

I believe at this stage we're OK with setting just 1 (e.g. Programmed). Changing this API in the future will be simple so accommodate for in consumers (KGO) so I'm OK with allowing a single condition in the declaration here.

Copy link
Contributor

Choose a reason for hiding this comment

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

How about not adding another field and having it granular per member, but only populating a MembersReferencesResolved condition in the CP's conditions? That would be True if all are valid, and False if any are invalid (with a message indicating which ones).

When creating Kong/gateway-operator#797 I didn't take that into account, but I think that might be easier to implement and cleaner.

Copy link
Member

Choose a reason for hiding this comment

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

👍 This would already be a nice improvement and as you've mentioned: will be easier, less error prone and more efficient to implement.

WDYT @randmonkey ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It sounds good to add a specific condition type in the CP representing the CP group. For further details, we can add fields map[string]MemeberStatus for status of each member. The detail part could be in the next release. How about this?

Copy link
Member

Choose a reason for hiding this comment

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

Let's focus on the CP group condition like suggested by @czeslavo - MembersReferencesResolved. At this point, I'd treat adding status conditions for each members as a nice to have, until requested by a user.

Copy link
Member

Choose a reason for hiding this comment

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

Can we add tests here for the added field?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I tried but it requires "error happens in updating status". This requires more changes in the testing framework.

Copy link
Member

Choose a reason for hiding this comment

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

Since this change introduces CEL validation, I'd halt merging this until we can figure out what is the cause of this error. We don't want to merge a change that would break updating the CP CRD for any supported use case.

Copy link
Contributor

Choose a reason for hiding this comment

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

I'm not sure if we should validate status fields with CEL rules 🤔 It will only be populated by the controller - that's where we should ensure it's generated valid.

Copy link
Member

Choose a reason for hiding this comment

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

Good point @czeslavo. This makes a lot of sense. 👍

Comment on lines +76 to +78
// MemberStatus is the status of each member in the control plane group.
// This field is only applicable for control planes with spec.cluster_type = CLUSTER_TYPE_CONTROL_PLANE_GROUP.
MemberStatus map[string][]metav1.Condition `json:"members,omitempty"`
Copy link
Member

Choose a reason for hiding this comment

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

Just to allow an extension of this field in the future, I suggest to put the conditions in a struct, which could then have other fields added in the future.

Suggested change
// MemberStatus is the status of each member in the control plane group.
// This field is only applicable for control planes with spec.cluster_type = CLUSTER_TYPE_CONTROL_PLANE_GROUP.
MemberStatus map[string][]metav1.Condition `json:"members,omitempty"`
// MembersStatus is the status of each member in the control plane group.
// This field is only applicable for control planes with spec.cluster_type = CLUSTER_TYPE_CONTROL_PLANE_GROUP.
MembersStatus map[string][]metav1.Condition `json:"members,omitempty"`

@randmonkey randmonkey marked this pull request as draft October 29, 2024 02:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants