Accept v1beta3 relationship schemaVersion at registration by leecalcote · Pull Request #1096 · meshery/meshkit

leecalcote · 2026-08-18T20:26:01Z

Description

This PR fixes #1095.

getEntity dispatched relationship documents only on the v1beta2 and v1alpha3 schema version strings, so a definition authored against the canonical v1beta3 construct published by meshery/schemas fell through to the default case and failed to register - in Meshery Server seeding and mesheryctl model import alike. Components and models in the same switch already accept both their legacy and current version strings; relationships were left out of that compatibility pattern.

Changes

Accept relationships.meshery.io/v1beta3 in the relationship case, decoding into the same shape-compatible registration struct (meshery/meshery's relationship_version_bridge.go already round-trips these shapes with shallow typed copies).
Add RelationshipSchemaVersionV1Beta3 beside the existing v1beta2 constant in schema/validator.go.
Tests: v1beta3 acceptance plus a pin that unknown versions are still rejected.

Verification

go build ./... - clean
go test ./... - full suite passes
golangci-lint run models/registration/... schema/... - 0 issues

Cross-repo context

meshery/meshery#21479 documents v1beta3 as the relationship authoring target; until this fix reaches a meshkit release consumed by meshery/meshery, definitions that must register on current servers still need to declare v1beta2 (that PR's wording is being corrected to say exactly that).

Summary by CodeRabbit

New Features
- Added support for relationship schema version v1beta3.
- Existing supported relationship versions continue to work as before.
Bug Fixes
- Unknown relationship schema versions are now correctly rejected.
Tests
- Added coverage for accepting v1beta3 and rejecting unsupported versions.

getEntity dispatched relationships only on the v1beta2 and v1alpha3 schema version strings, so a definition authored against the canonical v1beta3 construct published by meshery/schemas fell through to the default case and failed to register - in server seeding and in mesheryctl model import alike. Components and models in the same switch already accept both their legacy and current version strings. Accept relationships.meshery.io/v1beta3 in the relationship case, decoding into the same shape-compatible registration struct, and add a RelationshipSchemaVersionV1Beta3 constant beside the existing v1beta2 one. Cover acceptance of the new version and rejection of unknown versions in tests. Fixes #1095 Signed-off-by: Arjun Mehta <231106746+arjunmehta-git@users.noreply.github.com>

coderabbitai · 2026-08-18T20:26:25Z

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: dd6b08b8-6129-4999-b25a-f947bf612e47

📥 Commits

Reviewing files that changed from the base of the PR and between cf39c57 and 1089784.

📒 Files selected for processing (3)

models/registration/utils.go
models/registration/utils_test.go
schema/validator.go

Included review availability: Your plan provides up to 2 included reviews per hour; 1 remains after this review.

📝 Walkthrough

Walkthrough

The relationship entity parser now accepts the v1beta3 schema version. The schema package defines the corresponding exported constant. Tests cover successful v1beta3 parsing and rejection of the unknown v1beta9 version.

Changes

Relationship schema support

Layer / File(s)	Summary
Add v1beta3 schema dispatch `schema/validator.go`, `models/registration/utils.go`	The schema package defines `RelationshipSchemaVersionV1Beta3`. The relationship parser accepts this version and decodes it as the existing v1alpha3 relationship definition.
Validate accepted and unknown versions `models/registration/utils_test.go`	Tests verify successful parsing for `v1beta3` and an error for unknown version `v1beta9`.

Estimated code review effort: 2 (Simple) | ~10 minutes

Merge Risk: ⚪ Minimal · up to 10897

This PR enables registration of v1beta3 relationship definitions while preserving rejection of unknown versions, with no actionable merge-blocking risk remaining after normal checks and review.

Possibly related issues

Issue 1095: Directly requests v1beta3 relationship schema support in the parser, schema constants, and tests.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 25.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and concisely describes the main change: accepting the v1beta3 relationship schema version during registration.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches 💡 1

📝 Generate docstrings 💡

Create stacked PR
Commit on current branch

🧪 Generate unit tests (beta)

Create PR with unit tests
Commit unit tests in branch fix/register-v1beta3-relationships

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands.}

The earlier wording claimed v1beta3-authored definitions are consumed the same way as v1beta2 today. Shape-wise that is true (the server bridges registered definitions for the policy engine), but meshkit's registration switch accepts only v1beta2/v1alpha3 relationship documents, so a v1beta3 file fails to register at all - in server seeding and mesheryctl model import alike. meshery/meshkit#1096 adds the missing case (issue meshery/meshkit#1095). State the gate precisely everywhere the version guidance appears: author against v1beta3, declare v1beta2 for anything that must register on current servers. Also fold in skill-review feedback: trigger phrases and the file-path pattern move into the skill's frontmatter description, and the combo table now says to open only the matching example fixture. Signed-off-by: Lee Calcote <7570704+leecalcote@users.noreply.github.com>

leecalcote · 2026-08-19T20:37:13Z

Acknowledging the CodeRabbit walkthrough: it raised no actionable comments; lint, tests, and tidy are green on the current head.

The earlier wording claimed v1beta3-authored definitions are consumed the same way as v1beta2 today. Shape-wise that is true (the server bridges registered definitions for the policy engine), but meshkit's registration switch accepts only v1beta2/v1alpha3 relationship documents, so a v1beta3 file fails to register at all - in server seeding and mesheryctl model import alike. meshery/meshkit#1096 adds the missing case (issue meshery/meshkit#1095). State the gate precisely everywhere the version guidance appears: author against v1beta3, declare v1beta2 for anything that must register on current servers. Also fold in skill-review feedback: trigger phrases and the file-path pattern move into the skill's frontmatter description, and the combo table now says to open only the matching example fixture. Signed-off-by: Lee Calcote <7570704+leecalcote@users.noreply.github.com>

…elationships The kubernetes Ingress-to-Service relationship patched backend.serviceName / backend.servicePort - the extensions/v1beta1 Ingress shape removed in Kubernetes 1.22 - so forming the relationship wrote fields that do not exist in the networking.k8s.io/v1 component schema it ships beside. Rewrite the mutated paths to backend.service.name / backend.service.port.number in all 18 kubernetes version directories and give the definition a real description. The integration-spreadsheet row must be synced by a maintainer with sheet access or a future regeneration reintroduces the removed shape. Add the missing Ingress relationship coverage (kubernetes v1.37.0-rc.0): - defaultBackend -> Service (edge/non-binding/network): the catch-all backend when no rule matches. - IngressClass -> Ingress (edge/non-binding/reference): populates spec.ingressClassName. - Secret -> Ingress (edge/non-binding/reference): populates the first TLS entry's secretName. Give cert-manager (v1.21.1) its first relationship definitions: - Certificate -> Ingress: keeps spec.tls.0.secretName in sync with the Certificate's spec.secretName. - ClusterIssuer/Issuer -> Ingress: populates the ingress-shim cert-manager.io/cluster-issuer / cert-manager.io/issuer annotations. - ClusterIssuer/Issuer -> Certificate: populates spec.issuerRef name and kind (kind via the component.kind path, per corpus precedent). All definitions declare v1beta2 (the schemaVersion meshkit registration accepts today; see meshery/meshkit#1096) and every mutator/mutated path is verified against the shipped component schemas. Fixes meshery#21482 Signed-off-by: Lee Calcote <7570704+leecalcote@users.noreply.github.com>

The earlier wording claimed v1beta3-authored definitions are consumed the same way as v1beta2 today. Shape-wise that is true (the server bridges registered definitions for the policy engine), but meshkit's registration switch accepts only v1beta2/v1alpha3 relationship documents, so a v1beta3 file fails to register at all - in server seeding and mesheryctl model import alike. meshery/meshkit#1096 adds the missing case (issue meshery/meshkit#1095). State the gate precisely everywhere the version guidance appears: author against v1beta3, declare v1beta2 for anything that must register on current servers. Also fold in skill-review feedback: trigger phrases and the file-path pattern move into the skill's frontmatter description, and the combo table now says to open only the matching example fixture. Signed-off-by: Lee Calcote <7570704+leecalcote@users.noreply.github.com>

leecalcote self-assigned this Aug 18, 2026

This was referenced Aug 18, 2026

[Server] Model seeding logs 'unsupported extension' registration errors for its own .rego policy files meshery/meshery#21484

Open

[Models] Fix Ingress v1 backend paths; add Ingress and cert-manager relationship coverage meshery/meshery#21491

Merged

Navigation Menu

Uh oh!

Accept v1beta3 relationship schemaVersion at registration - #1096

Accept v1beta3 relationship schemaVersion at registration#1096
leecalcote wants to merge 1 commit into
masterfrom
fix/register-v1beta3-relationships

leecalcote commented Aug 18, 2026 •

edited by coderabbitai Bot

Loading

Uh oh!

coderabbitai Bot commented Aug 18, 2026 •

edited

Loading

Walkthrough

Changes

❌ Failed checks (1 warning)

Uh oh!

leecalcote commented Aug 19, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

leecalcote commented Aug 18, 2026 • edited by coderabbitai Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary by CodeRabbit

Uh oh!

coderabbitai Bot commented Aug 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Walkthrough

Changes

❌ Failed checks (1 warning)

Uh oh!

leecalcote commented Aug 19, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

leecalcote commented Aug 18, 2026 •

edited by coderabbitai Bot

Loading

coderabbitai Bot commented Aug 18, 2026 •

edited

Loading