Repository navigation
fix(api): correct LocalASN OpenAPI format to int64 - #3054
Merged
Merged
Conversation
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request updates the validation format for the LocalASN field in the BGPPeer CRD from int32 to int64 across the Go type definitions, Helm charts, and generated manifests. This ensures that the full range of a uint32 (up to 4294967295) is correctly handled by the Kubernetes API validation, as the previous int32 format was insufficient. I have no feedback to provide as there were no review comments.
The BGPPeer v1beta2 spec declared LocalASN with the kubebuilder annotation `+kubebuilder:validation:Maximum=4294967295` but no `Format` annotation, so controller-gen emitted `format: int32` in the generated CRD. int32 cannot represent 4,294,967,295 (its maximum is 2,147,483,647), so the schema is internally inconsistent. The sibling fields `ASN` (peerASN) and `MyASN` already carry `+kubebuilder:validation:Format=int64` for the same uint32 type with the same maximum. Align LocalASN with them: a one-line annotation addition + the matching controller-gen regeneration of the CRDs and the all-in-one manifests. Found during downstream consumer review while bumping cozystack to MetalLB v0.16.0; see cozystack/cozystack#2699 for the trigger context. Signed-off-by: Aleksei Sviridkin <[email protected]>
lexfrei
force-pushed
the
fix/bgppeer-localasn-int64
branch
from
May 21, 2026 10:17
21c03d2 to
4fbaf0f
Compare
1 task
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Is this a BUG FIX or a FEATURE ?:
/kind bug
What this PR does / why we need it:
BGPPeer.spec.localASN(added in v0.16.0) declares+kubebuilder:validation:Maximum=4294967295but noFormatannotation. controller-gen therefore emitsformat: int32in the generated CRD, which is internally inconsistent: int32's maximum is 2,147,483,647 — the schema's declared maximum (4,294,967,295) exceeds it.The sibling fields
ASN(peerASN) andMyASNon the same struct already carry+kubebuilder:validation:Format=int64for the sameuint32Go type and the same Maximum. This PR alignsLocalASNwith them.Diff scope:
api/v1beta2/bgppeer_types.go: one added annotation line (matches sibling-field pattern).config/crd/bases/metallb.io_bgppeers.yaml,charts/metallb/charts/crds/templates/crds.yaml, sixconfig/manifests/metallb-*.yaml: regenerated byinv generatemanifests, each file changes a singleformat: int32→format: int64line for thelocalASNproperty.No runtime change — internal Go types for
LocalASNare alreadyuint32end-to-end. Schema-only fix.Special notes for your reviewer:
Reproduce the regeneration with Python invoke and the deps from
tasks.py:Release note: