enhancments, status-crd: Rename CRD name by ormergi · Pull Request #340 · openperouter/openperouter

ormergi · 2026-04-27T08:29:02Z

Is this a BUG FIX or a FEATURE ?:

Uncomment only one, leave it on its own line:

/kind bug
/kind cleanup
/kind feature
/kind design
/kind flake
/kind failing
/kind documentation
/kind regression
/kind example

What this PR does / why we need it:
The enhancement states the project should follows existing examples such as k8s-nmstate and frr-k8s [1].
These project CRD names are 'NodeNetworkState' [2] 'FRRNodeState' [3]. In addition the sriov-network-operator provide similar status API, its CRD name is 'SriovNetworkNodeState' [4].
The pattern here is 'NodeState'.

Change the suggested CRD name to RouterNodeState.

The new name follows the mentioned statement and describe better what the CRD represent; not only a configuration status but a complete state.

[1] https://github.com/openperouter/openperouter/blob/main/enhancements/status-crd.md#:~:text=This%20design%20follows%20established%20patterns%20from%20kubernetes-nmstate%20and%20frr-k8s
[2] https://nmstate.io/kubernetes-nmstate/user-guide/101-reporting.html
[3] https://github.com/metallb/frr-k8s#checking-the-status-of-each-frr-instance
[4] https://github.com/k8snetworkplumbingwg/sriov-network-operator/blob/master/doc/api/node-state-api.md#sriovnetworknodestate-api-reference

Special notes for your reviewer:

Release note:

The enhancement states the project should follows existing examples such as k8s-nmstate and frr-k8s [1]. These project CRD names are 'NodeNetworkState' [2] 'FRRNodeState' [3]. In addition the sriov-network-operator provide similar status API, its CRD name is 'SriovNetworkNodeState' [4]. The pattern here is '<component name>NodeState'. Change the suggested CRD name to RouterNodeState. The new name follows the mentioned statement and describe better what the CRD represent; not only a configuration status but a complete state. [1] github.com/openperouter/openperouter/blob/main/enhancements/status-crd.md#:~:text=This design follows established patterns from kubernetes-nmstate and frr-k8s [2] https://nmstate.io/kubernetes-nmstate/user-guide/101-reporting.html [3] https://github.com/metallb/frr-k8s#checking-the-status-of-each-frr-instance [4] https://github.com/k8snetworkplumbingwg/sriov-network-operator/blob/master/doc/api/node-state-api.md#sriovnetworknodestate-api-reference Signed-off-by: Or Mergi <ormergi@redhat.com>

gemini-code-assist · 2026-04-27T08:29:09Z

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request updates the naming convention for the status Custom Resource Definition (CRD) to better align with industry standards and existing Kubernetes operators. By renaming the resource to 'RouterNodeState', the project adopts a more descriptive and consistent naming pattern that accurately reflects its role in representing the complete state of a node.

Highlights

CRD Renaming: Renamed the 'RouterNodeConfigurationStatus' CRD to 'RouterNodeState' to align with established Kubernetes operator patterns.
Documentation Update: Updated all design documentation, examples, and RBAC permissions in the enhancement proposal to reflect the new CRD name.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	`/gemini review`	Performs a code review for the current pull request in its current state.
Pull Request Summary	`/gemini summary`	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	`/gemini help`	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

ormergi · 2026-04-27T08:29:16Z

/cc @fedepaol @maiqueb

gemini-code-assist

Code Review

This pull request renames the RouterNodeConfigurationStatus CRD to RouterNodeState throughout the enhancement documentation, updating API structures, YAML examples, and CLI commands. The review feedback focuses on improving the robustness of the provided jq examples to handle null or missing status fields, ensuring the commands work correctly for healthy nodes or before the first reconciliation.

gemini-code-assist · 2026-04-27T08:30:46Z


 # Get status with conditions for monitoring
-kubectl get routernodeconfigurationstatus -o json | jq '.items[] | {name: .metadata.name, ready: (.status.conditions[] | select(.type=="Ready") | .status)}'
+kubectl get routernodestate -o json | jq '.items[] | {name: .metadata.name, ready: (.status.conditions[] | select(.type=="Ready") | .status)}'


The jq query will fail if .status.conditions is null (which is common before the first reconciliation) or if no "Ready" condition exists (it will omit the node entirely from the output). Using the optional chaining operator []? and first() with a default value makes the example more robust for users.

Suggested change

kubectl get routernodestate -o json | jq '.items[] | {name: .metadata.name, ready: (.status.conditions[] | select(.type=="Ready") | .status)}'

kubectl get routernodestate -o json | jq '.items[] | {name: .metadata.name, ready: (first(.status.conditions[]? | select(.type=="Ready") | .status) // "Unknown")}'

This out of this PR scope.

why ? iiuc, it might happen

This PR merely change the CRD name

gemini-code-assist · 2026-04-27T08:30:46Z


 # Check failed configurations
-kubectl get routernodeconfigurationstatus -o json | jq '.items[] | select(.status.failedResources | length > 0) | {node: .metadata.name, failed: [.status.failedResources[] | "\(.kind)/\(.name): \(.message)"]}'
+kubectl get routernodestate -o json | jq '.items[] | select(.status.failedResources | length > 0) | {node: .metadata.name, failed: [.status.failedResources[] | "\(.kind)/\(.name): \(.message)"]}'


The jq query will error with null (null) has no length for any healthy node where failedResources is not present (due to omitempty). It is safer to use the alternative operator // [] to handle null values before checking the length, and []? to ensure safe iteration.

Suggested change

kubectl get routernodestate -o json | jq '.items[] | select(.status.failedResources | length > 0) | {node: .metadata.name, failed: [.status.failedResources[] | "\(.kind)/\(.name): \(.message)"]}'

kubectl get routernodestate -o json | jq '.items[] | select((.status.failedResources // []) | length > 0) | {node: .metadata.name, failed: [.status.failedResources[]? | "\(.kind)/\(.name): \(.message)"]}'

This out of this PR scope.

why ? it might happen iiuc

This PR merely change the CRD name

maiqueb

but honestly, to me, this doesn't improve the project. Hopefully you're right, and it'll be simpler for people onboarding the project.

maiqueb · 2026-04-27T11:13:18Z

@qinqon thoughts ?

qinqon · 2026-04-27T11:48:09Z

@qinqon thoughts ?

Not sure this is right,

I think "Configuration" was fine, the NodeNetworkState is not realted to any configuration is just the networking present at node.

Like without "Configuration" (no underlay, no l3vni or no l2vni) there is nothing to check but at knmstate we have NodeNetworkState even if we don't have a NNCP configured.

ormergi · 2026-05-03T12:30:23Z

Thanks for the feedback, nmstate perspective is nice

The "ConfigurationStatus" notation is some what limiting for the configuration only, I think using the "State" notation is more future proof and is not limiting only for the configuration.

For example, one could look into the status API to find the additional NICs and create Underlay objects accordingly, w/o exec into the node or check other APIs (such as NMstate's or SR-IOV).

In addition the "ConfigurationStatus" naming produce some awkward component name, such as the struct that describe the CRD status "ConfigurationStatusStatus".

fedepaol · 2026-05-14T08:43:49Z

Thanks for the feedback, nmstate perspective is nice

The "ConfigurationStatus" notation is some what limiting for the configuration only, I think using the "State" notation is more future proof and is not limiting only for the configuration.

For example, one could look into the status API to find the additional NICs and create Underlay objects accordingly, w/o exec into the node or check other APIs (such as NMstate's or SR-IOV).

If we want to expose extra status not related to configuration, imo it's gonna be better to use a different - per domain scoped - CRD. I don't think having a gigantic resource with the status of the current config, the status of the bgp sessions or other stuff is gonna be better for the user's eyes (plus, it's going to be hard to get a one liner summary of the state if the state involves many things altogether.

In addition the "ConfigurationStatus" naming produce some awkward component name, such as the struct that describe the CRD status "ConfigurationStatusStatus".

That's true, but it's also true that no one will write or consume it alone, but as config.Status. We can rename to State but I don't see a lot of value in it tbh

gemini-code-assist Bot reviewed Apr 27, 2026

View reviewed changes

maiqueb approved these changes Apr 27, 2026

View reviewed changes

github-actions Bot added the kind/design label Apr 27, 2026

maiqueb requested a review from fedepaol April 27, 2026 11:13

	kubectl get routernodestate -o json \| jq '.items[] \| {name: .metadata.name, ready: (.status.conditions[] \| select(.type=="Ready") \| .status)}'
	kubectl get routernodestate -o json \| jq '.items[] \| {name: .metadata.name, ready: (first(.status.conditions[]? \| select(.type=="Ready") \| .status) // "Unknown")}'

Conversation

ormergi commented Apr 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

gemini-code-assist Bot commented Apr 27, 2026

Summary of Changes

Highlights

Footnotes

Uh oh!

ormergi commented Apr 27, 2026

Uh oh!

gemini-code-assist Bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

gemini-code-assist Bot Apr 27, 2026

Choose a reason for hiding this comment

Uh oh!

ormergi Apr 27, 2026

Choose a reason for hiding this comment

Uh oh!

maiqueb Apr 27, 2026

Choose a reason for hiding this comment

Uh oh!

ormergi Apr 27, 2026

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist Bot Apr 27, 2026

Choose a reason for hiding this comment

Uh oh!

ormergi Apr 27, 2026

Choose a reason for hiding this comment

Uh oh!

maiqueb Apr 27, 2026

Choose a reason for hiding this comment

Uh oh!

ormergi Apr 27, 2026

Choose a reason for hiding this comment

Uh oh!

maiqueb left a comment

Choose a reason for hiding this comment

Uh oh!

maiqueb commented Apr 27, 2026

Uh oh!

qinqon commented Apr 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ormergi commented May 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

fedepaol commented May 14, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

ormergi commented Apr 27, 2026 •

edited

Loading

qinqon commented Apr 27, 2026 •

edited

Loading

ormergi commented May 3, 2026 •

edited

Loading