Skip to content
This repository was archived by the owner on Sep 9, 2026. It is now read-only.

OSAC-3339: validate field_definition paths against proto schema and template parameters - #996

Closed
alosadagrande wants to merge 2 commits into
osac-project:mainfrom
alosadagrande:fix/OSAC-3339
Closed

alosadagrande wants to merge 2 commits into
osac-project:mainfrom
alosadagrande:fix/OSAC-3339

Conversation

@alosadagrande

@alosadagrande alosadagrande commented Jul 30, 2026 •

Copy link
Copy Markdown
Contributor

Summary

  • Field definition path validation: Add proto-reflection-based validation of field_definition paths against the spec message descriptor (ClusterSpec, ComputeInstanceSpec, BareMetalInstanceSpec) at catalog item Create/Update time. Invalid paths are rejected with an InvalidArgument error listing the valid fields.
  • Template parameter validation: Add validation of template_parameters.* paths against the referenced template's declared parameters. If a field definition references an unknown parameter, the error lists valid parameter names.
  • Shared validation logic: Extract the validation into catalog_item_validation.go as shared functions used by all three catalog item servers, using a templateResolver function type for dependency injection of template lookups.
  • Proto comment fixes: Correct FieldDefinition.path examples in both public and private proto files — paths are relative to the spec message (e.g. network.pod_cidr), not prefixed with spec..
  • Server-level validation tests: Add 12 new tests (4 per server × 3 servers) verifying that Create and Update reject invalid spec paths and unknown template parameters.

Jira

OSAC-3339

Test plan

  • gofmt -s -w . — no formatting changes
  • buf lint + buf generate — proto lint passes, generated code up to date
  • go build ./... — compiles cleanly
  • ginkgo run -r internal — 83 suites pass (including 12 new validation tests)
  • All changed production files have corresponding test changes

🤖 Generated with Claude Code

Summary by CodeRabbit

  • Validation Improvements

    • Catalog item field definitions now reject invalid resource-spec paths during creation and updates.
    • Template parameter references are validated against the selected template.
    • Clear invalid-argument errors identify unknown fields or parameters.
  • Documentation

    • Clarified that field-definition paths are relative to the resource specification and use dot notation without a spec. prefix.

@openshift-ci-robot

openshift-ci-robot commented Jul 30, 2026 •

Copy link
Copy Markdown

@alosadagrande: This pull request references OSAC-3339 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the bug to target the "5.0.0" version, but no target version was set.

Details

In response to this:

Summary

  • Shared validation logic: Extract duplicated validateFieldDefinitionPathsAndTemplateParams and validateTemplateParams from the three catalog item servers (cluster, compute instance, bare metal) into catalog_item_validation.go. Each server now delegates to shared functions via a templateResolver function type for dependency injection of template lookups, reducing ~50 duplicated lines per server to ~10.
  • Proto comment fixes: Correct FieldDefinition.path examples in both public and private proto files — paths are relative to the spec message (e.g. network.pod_cidr), not prefixed with spec. as the comments previously showed.
  • Server-level validation tests: Add 12 new tests (4 per server × 3 servers) verifying that Create and Update reject invalid spec paths and unknown template parameters. Each test file includes a helper that inserts a real template into the test database so parameter validation reaches the name-checking stage.

Jira

OSAC-3339

Test plan

  • gofmt -s -w . — no formatting changes
  • buf lint + buf generate — proto lint passes, generated code up to date
  • go build ./... — compiles cleanly
  • ginkgo run -r internal — 83 suites pass (including 12 new validation tests)
  • All changed production files have corresponding test changes

🤖 Generated with Claude Code

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 openshift-eng/jira-lifecycle-plugin repository.

@coderabbitai

coderabbitai Bot commented Jul 30, 2026 •

Copy link
Copy Markdown

Review Change Stack

Warning

Review limit reached

@alosadagrande, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 57 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details
⚙️ Run configuration

Configuration used: Repository: osac-project/coderabbit/.coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 9c898b22-b38e-434f-8153-a1b5147af4ba

📥 Commits

Reviewing files that changed from the base of the PR and between 4c40d44 and 6b6f18e.

⛔ Files ignored due to path filters (4)
  • internal/api/osac/private/v1/field_definition_type.pb.go is excluded by !**/*.pb.go
  • internal/api/osac/private/v1/field_definition_type_protoopaque.pb.go is excluded by !**/*.pb.go
  • internal/api/osac/public/v1/field_definition_type.pb.go is excluded by !**/*.pb.go
  • internal/api/osac/public/v1/field_definition_type_protoopaque.pb.go is excluded by !**/*.pb.go
📒 Files selected for processing (10)
  • internal/servers/catalog_item_validation.go
  • internal/servers/catalog_item_validation_test.go
  • internal/servers/private_baremetal_instance_catalog_items_server.go
  • internal/servers/private_baremetal_instance_catalog_items_server_test.go
  • internal/servers/private_cluster_catalog_items_server.go
  • internal/servers/private_cluster_catalog_items_server_test.go
  • internal/servers/private_compute_instance_catalog_items_server.go
  • internal/servers/private_compute_instance_catalog_items_server_test.go
  • proto/private/osac/private/v1/field_definition_type.proto
  • proto/public/osac/public/v1/field_definition_type.proto

Walkthrough

Catalog item validation now checks spec-relative field-definition paths and template parameter references. Bare-metal, cluster, and compute servers resolve templates during Create and Update, with expanded tests and updated path documentation.

Changes

Catalog item validation

Layer / File(s) Summary
Descriptor and template validation
internal/servers/catalog_item_validation.go, internal/servers/catalog_item_validation_test.go, proto/*/osac/*/v1/field_definition_type.proto
Validates nested, scalar, map, and template-parameter paths against descriptors and reports structured gRPC errors.
Bare-metal validation integration
internal/servers/private_baremetal_instance_catalog_items_server.go, internal/servers/private_baremetal_instance_catalog_items_server_test.go
Adds template resolution and Create/Update validation for bare-metal catalog items.
Cluster validation integration
internal/servers/private_cluster_catalog_items_server.go, internal/servers/private_cluster_catalog_items_server_test.go
Adds cluster template resolution and rejects invalid field paths and unknown template parameters.
Compute validation integration
internal/servers/private_compute_instance_catalog_items_server.go, internal/servers/private_compute_instance_catalog_items_server_test.go
Adds compute template resolution, validates paths before instance-type checks, and updates instance-type path handling.

Estimated code review effort: 4 (Complex) | ~45 minutes

Sequence Diagram(s)

sequenceDiagram
  participant Client
  participant CatalogItemServer
  participant CatalogItemValidation
  participant TemplatesDAO
  Client->>CatalogItemServer: Create or Update catalog item
  CatalogItemServer->>CatalogItemValidation: validate field definitions
  CatalogItemValidation->>TemplatesDAO: resolve referenced template
  TemplatesDAO-->>CatalogItemValidation: template definition
  CatalogItemValidation-->>CatalogItemServer: InvalidArgument or success
  CatalogItemServer-->>Client: validation response
Loading

Possibly related PRs

Suggested labels: jira/valid-reference, approved, lgtm, ok-to-test

Suggested reviewers: rgolangh, jhernand, ygalblum

🚥 Pre-merge checks | ✅ 10 | ❌ 1

❌ Failed checks (1 warning)

Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 36.36% which is insufficient. The required threshold is 80.00%. Write docstrings for the functions missing them to satisfy the coverage threshold.
✅ Passed checks (10 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title clearly describes the main change: validating field_definition paths against proto schema and template parameters.
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.
No-Hardcoded-Secrets ✅ Passed No hardcoded secrets found in changed production files; only placeholder strings like 'my-secret' appear in *_test.go files and չեն match real-secret patterns.
No-Weak-Crypto ✅ Passed No weak crypto, custom crypto, or secret/token comparisons appear in the changed server/proto files; only validation/path logic was added.
No-Injection-Vectors ✅ Passed No flagged sinks appear in the touched files; validation code only reflects/validates paths and template params, and searches found no eval/exec, shell, YAML, pickle, SQL, or HTML injection patterns.
Container-Privileges ✅ Passed PR touches only Go/proto/test files; no container/K8s manifests changed, and no privilege-related settings appear in touched files.
No-Sensitive-Data-In-Logs ✅ Passed No new log statements were added in the changed files; the new helpers only return validation errors and DAO lookups, not logged secrets.
Ai-Attribution ✅ Passed HEAD commit includes Assisted-by: Claude Code <noreply@anthropic.com> and no Co-Authored-By trailer.
✨ Finishing Touches 💡 1
🛠️ Fix failing CI checks 💡
  • Fix failing CI checks
🧪 Generate unit tests (beta)
  • Create PR with unit tests

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.

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Actionable comments posted: 5

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (3)
internal/servers/private_baremetal_instance_catalog_items_server.go (1)

170-182: 🎯 Functional Correctness | 🟠 Major | 🏗️ Heavy lift

Validate the post-merge catalog item before checking template parameters.

For masked updates like mask: ["field_definitions"], request.GetObject().GetTemplate() is the raw value, while s.generic.Update later merges the persisted template into the draft object first. A partial update that only modifies field_definitions and leaves template parameter definitions intact therefore passes this pre-merge check even when adding new invalid template_parameters.* field definitions, and can fail later with schema validation or incorrect apply behavior. Use the draft object after the generic merge for validateFieldDefinitionPaths, not the unmerged request object.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@internal/servers/private_baremetal_instance_catalog_items_server.go` around
lines 170 - 182, The Update method currently validates template parameter paths
on the unmerged request object. Ensure the generic merge runs before
validateFieldDefinitionPathsAndTemplateParams, then validate the resulting draft
object while preserving field-definition validation and existing error
propagation.
internal/servers/private_compute_instance_catalog_items_server.go (1)

164-187: 🎯 Functional Correctness | 🟠 Major | ⚡ Quick win

Validate on the updated catalog item, not the request object.

Update calls validateFieldDefinitionPathsAndTemplateParams(ctx, object) before s.generic.Update applies the field mask, so a field-mask update that only changes field_definitions uses object.GetTemplateId() from the request object. Move this validation to the merged object, or load/use the current object’s template fields before validating template_parameters.* paths.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@internal/servers/private_compute_instance_catalog_items_server.go` around
lines 164 - 187, Update the Update method so
validateFieldDefinitionPathsAndTemplateParams runs against the catalog item
after s.generic.Update applies the field mask, using the merged object’s
template fields. Preserve field-definition validation and warning handling, and
ensure template_parameters.* path validation uses the updated catalog item
rather than the partial request object.
internal/servers/private_cluster_catalog_items_server.go (1)

142-154: 🎯 Functional Correctness | 🟠 Major | 🏗️ Heavy lift

Validate against the persisted template before applying a partial update.

Update validates request.GetObject().GetTemplate() before calling s.generic.Update, but the public update path may merge only changed field_definitions onto the existing catalog item. If template is not resented in that update, the request object can have an empty template and validation skips template_parameters.* checks; use the existing private catalog item’s template for this validation.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@internal/servers/private_cluster_catalog_items_server.go` around lines 142 -
154, Update PrivateClusterCatalogItemsServer.Update to load the existing private
catalog item before validating partial updates, and use its persisted template
when request.GetObject().GetTemplate() is empty or omitted. Ensure
validateFieldDefinitionPathsAndTemplateParams validates template_parameters.*
against that persisted template before s.generic.Update applies changes, while
preserving request-provided template behavior.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@internal/servers/catalog_item_validation.go`:
- Around line 140-183: Update validateFieldDefinitionTemplateParams and the
corresponding validation logic around hasTemplateParamPaths to recognize the
bare "template_parameters" path as a template-parameter path, matching
validateFieldDefinitionPaths’ first-segment behavior rather than requiring a
trailing dot. Ensure the malformed path is validated and rejected, and add a
regression test in catalog_item_validation_test.go covering the exact path
"template_parameters".
- Around line 94-127: Update validatePathAgainstDescriptor to reject dot-path
traversal through non-map repeated message fields unless the path explicitly
includes an element index. Preserve nested traversal for singular messages and
map values, and adjust path parsing/validation so map key segments containing
dots are treated as a single escaped or otherwise explicitly denoted key rather
than split into nested field segments.

In `@internal/servers/private_baremetal_instance_catalog_items_server.go`:
- Around line 207-223: Extract the repeated DAO lookup and error-mapping logic
from resolveTemplate into a shared generic helper, such as
resolveTemplateFromDAO, accepting the DAO, template ID, and adapter function.
Update resolveTemplate in the private bare-metal, cluster, and compute servers
to delegate to this helper while preserving each concrete response type’s
existing adapter.

In `@internal/servers/private_cluster_catalog_items_server.go`:
- Around line 167-183: Extract the duplicated template lookup, error mapping,
and adapter construction from resolveTemplate into a shared generic helper
reusable by the private cluster, bare-metal, and compute catalog item servers.
Update each server’s resolveTemplate method to delegate to that helper while
preserving the existing DAO, templateLookupError, and adapter behavior.

In `@internal/servers/private_compute_instance_catalog_items_server.go`:
- Around line 201-216: Extract the repeated template lookup, error mapping, and
adapter construction from resolveTemplate into a shared generic helper reusable
by the private compute instance, bare-metal, and cluster servers. Update each
server’s resolveTemplate to call the helper while preserving its existing DAO,
adapter, and templateLookupError behavior.

---

Outside diff comments:
In `@internal/servers/private_baremetal_instance_catalog_items_server.go`:
- Around line 170-182: The Update method currently validates template parameter
paths on the unmerged request object. Ensure the generic merge runs before
validateFieldDefinitionPathsAndTemplateParams, then validate the resulting draft
object while preserving field-definition validation and existing error
propagation.

In `@internal/servers/private_cluster_catalog_items_server.go`:
- Around line 142-154: Update PrivateClusterCatalogItemsServer.Update to load
the existing private catalog item before validating partial updates, and use its
persisted template when request.GetObject().GetTemplate() is empty or omitted.
Ensure validateFieldDefinitionPathsAndTemplateParams validates
template_parameters.* against that persisted template before s.generic.Update
applies changes, while preserving request-provided template behavior.

In `@internal/servers/private_compute_instance_catalog_items_server.go`:
- Around line 164-187: Update the Update method so
validateFieldDefinitionPathsAndTemplateParams runs against the catalog item
after s.generic.Update applies the field mask, using the merged object’s
template fields. Preserve field-definition validation and warning handling, and
ensure template_parameters.* path validation uses the updated catalog item
rather than the partial request object.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Repository: osac-project/coderabbit/.coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 5b5d94b3-0a19-44e5-86cd-fde6612d5f1a

📥 Commits

Reviewing files that changed from the base of the PR and between a15b93c and 4c40d44.

⛔ Files ignored due to path filters (4)
  • internal/api/osac/private/v1/field_definition_type.pb.go is excluded by !**/*.pb.go
  • internal/api/osac/private/v1/field_definition_type_protoopaque.pb.go is excluded by !**/*.pb.go
  • internal/api/osac/public/v1/field_definition_type.pb.go is excluded by !**/*.pb.go
  • internal/api/osac/public/v1/field_definition_type_protoopaque.pb.go is excluded by !**/*.pb.go
📒 Files selected for processing (10)
  • internal/servers/catalog_item_validation.go
  • internal/servers/catalog_item_validation_test.go
  • internal/servers/private_baremetal_instance_catalog_items_server.go
  • internal/servers/private_baremetal_instance_catalog_items_server_test.go
  • internal/servers/private_cluster_catalog_items_server.go
  • internal/servers/private_cluster_catalog_items_server_test.go
  • internal/servers/private_compute_instance_catalog_items_server.go
  • internal/servers/private_compute_instance_catalog_items_server_test.go
  • proto/private/osac/private/v1/field_definition_type.proto
  • proto/public/osac/public/v1/field_definition_type.proto

Comment thread internal/servers/catalog_item_validation.go
Comment thread internal/servers/catalog_item_validation.go
Comment thread internal/servers/private_baremetal_instance_catalog_items_server.go
Comment thread internal/servers/private_cluster_catalog_items_server.go
Comment thread internal/servers/private_compute_instance_catalog_items_server.go
…e parameters

Extract shared validation logic (validateCatalogItemFieldDefinitionPaths,
validateTemplateParams, templateLookupError) into catalog_item_validation.go
to eliminate duplication across the three catalog item servers.

Fix proto comments to reflect actual path format (relative to spec, not
prefixed with "spec.").

Add server-level tests verifying Create/Update reject invalid spec paths
and unknown template parameters for all three catalog item types.

OSAC-3339

Assisted-by: Claude Code <noreply@anthropic.com>
Signed-off-by: Alberto Losada Grande <alosadag@redhat.com>
A field_definition with path "template_parameters" (no dot suffix)
bypassed both spec path validation and template parameter validation.
Reject it early in validateFieldDefinitionPaths with a clear error
message.

Signed-off-by: Alberto Losada Grande <alosadagrande@gmail.com>
Assisted-by: Claude Code <noreply@anthropic.com>
Signed-off-by: Alberto Losada Grande <alosadag@redhat.com>
@alosadagrande

Copy link
Copy Markdown
Contributor Author

/retest

@github-actions

Copy link
Copy Markdown

Re-triggered failed runs:

  • E2E VMaaS Full Install (#30541851957)

@tzvatot tzvatot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Clean shared validation logic with excellent error messages. One important issue with Update validation timing.

Category Count
🔴 Critical 0
🟡 Important 1
💡 Suggestion 1

Comment on lines 145 to 147
if err = validateFieldDefinitions(object.GetFieldDefinitions()); err != nil {
return
}

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

🟡 Template param validation on Update uses pre-merge state

validateFieldDefinitionPathsAndTemplateParams runs on request.GetObject() before s.generic.Update performs the field mask merge. If a client sends a partial update with only field_definitions in the mask and omits template from the request body, item.GetTemplate() returns "". The validation then rejects with "no template is set" even though the persisted object has a valid template.

This applies to all three catalog item servers (cluster, compute instance, bare metal).

Fix: when templateRef is empty and the request has template_parameters.* paths, fetch the existing catalog item's template from the database before rejecting.

Comment on lines +70 to +89
// validateFieldDefinitionPaths checks that each field definition path corresponds to a valid field
// in the given spec message descriptor. Paths starting with "template_parameters" are skipped
// (validated separately by validateFieldDefinitionTemplateParams).
func validateFieldDefinitionPaths(
fieldDefinitions []*privatev1.FieldDefinition,
specDescriptor protoreflect.MessageDescriptor,
) error {
for _, fd := range fieldDefinitions {
path := fd.GetPath()
if path == "" {
continue
}
segments := strings.Split(path, ".")
if segments[0] == "template_parameters" {
if len(segments) == 1 {
return grpcstatus.Errorf(grpccodes.InvalidArgument,
"invalid field_definition path 'template_parameters': "+
"must specify a parameter name (e.g., 'template_parameters.param_name')")
}
continue

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

💡 Path validation stops at first error while template param validation collects all

validateFieldDefinitionPaths returns on the first invalid path, while validateFieldDefinitionTemplateParams collects all invalid parameters and reports them together. Consider collecting all invalid paths too so the caller can fix everything in one round trip. Minor UX inconsistency.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Also: "template_parameters" is hardcoded in 5 places across this file (lines 77, 80, 120, 189, 231+). Consider extracting a const like templateParametersPrefix = "template_parameters." - there is no existing constant in the codebase, but this PR adds enough new uses to justify one.

@openshift-ci

openshift-ci Bot commented Jul 30, 2026

Copy link
Copy Markdown

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: alosadagrande
Once this PR has been reviewed and has the lgtm label, please ask for approval from tzvatot. 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:

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

@tzvatot tzvatot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Test Review

Good unit test coverage for the validation functions (12 path tests + 3 template param tests). The 12 server-level integration tests verify wiring. Three missing test paths.

Category Count
🔴 Critical 0
🟡 Important 3
💡 Suggestion 1

🟡 No test for "no template is set" error path

validateTemplateParams rejects template_parameters.* paths when templateRef == "". This path is untested at both unit and server level. A catalog item with no template but with template_parameters.foo in field definitions should be rejected.

🟡 No test for template-not-found via DAO lookup

templateLookupError converts dao.ErrNotFound to InvalidArgument("template not found"). All server tests create the template first - none test referencing a nonexistent template ID with template parameter paths.

🟡 No happy-path server test with valid template parameters

All 12 new server tests are rejection tests. No positive test verifies that a Create with valid template_parameters.* paths against a template declaring those parameters actually succeeds through the full server wiring (template DAO lookup, adapter conversion).

💡 DescribeTable opportunity

The 4 tests per server follow identical structure across all three servers. The codebase uses DescribeTable in catalog_item_validation_test.go, but the different proto types make collapsing tricky. Acceptable duplication.

This branch was previously deployed

1 inactive deployment
e2e-test — 6b6f18e7 Deployed Jul 30, 2026 by alosadagrande via e2e-vmaas-full-install / e2e #875
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants