Skip to content

Conversation

@youngbupark
Copy link

@youngbupark youngbupark commented Oct 28, 2025

Summary

This is the initial commit of rollout plugin protobuf for the enhancement open-cluster-management-io/enhancements#160

Related issue(s)

Fixes #

Summary by CodeRabbit

  • New Features

    • Adds a rollout plugin service with initialization and advertised capabilities.
    • Introduces lifecycle RPCs for begin/progress/validate of rollout and abort/rollback with per-cluster status reporting.
    • Adds structured validation results (succeeded/failed/in-progress) and a pre-apply manifest mutation step to adjust manifestwork based on rollout state.
  • Chores

    • Adds code-generation metadata and developer guidance for regenerating plugin stubs.

@openshift-ci
Copy link

openshift-ci bot commented Oct 28, 2025

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: youngbupark
Once this PR has been reviewed and has the lgtm label, please assign deads2k for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

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

@coderabbitai
Copy link

coderabbitai bot commented Oct 28, 2025

Walkthrough

Adds a new v1alpha1 rollout protobuf and a go:generate stub. Declares RolloutPluginService RPCs for initialization, rollout/abort lifecycle, validation, and ManifestWork mutation, plus messages for metadata, per-cluster rollout status, rollout results, validation payloads, and manifest mutation.

Changes

Cohort / File(s) Summary
Rollout plugin proto + generator
pkg/plugin/proto/v1alpha1/gen.go, pkg/plugin/proto/v1alpha1/rollout.proto
Adds gen.go with a //go:generate directive to run protoc. Adds rollout.proto defining RolloutPluginService RPCs: Initialize, BeginRollout, ProgressRollout, ValidateRolloutCompletion, BeginAbort, ProgressAbort, ValidateAbortCompletion, MutateManifestWork. Declares messages: InitializeRequest, InitializeResponse (with nested Capabilities), ClusterRolloutStatus, RolloutResult, RolloutMetadata, RolloutPluginRequest, ValidateCompletionRequest, ValidateResponse (with Result enum and oneof payload), MutateManifestWorkRequest (with RolloutState enum, optional RolloutResult, and manifestwork as k8s.io.apimachinery.pkg.runtime.Unknown), and MutateManifestWorkResponse (with manifestwork).

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

  • Verify RPC and message names and semantics for consistency between rollout and abort flows.
  • Confirm proto imports (google.protobuf.Any, Kubernetes runtime Unknown) and package paths are correct for Go code generation.
  • Validate use of optional fields, enums, and oneof for intended semantics.

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)
Check name Status Explanation
Title check ✅ Passed The title clearly identifies the main change as the initial commit of rollout plugin protobuf, directly matching the changeset's introduction of rollout.proto and gen.go.
Description check ✅ Passed The description includes a concise summary and references the enhancement PR, but lacks details about what the protobuf defines and the motivations for these specific API structures.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
✨ Finishing touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between d81dd37 and efc7508.

⛔ Files ignored due to path filters (2)
  • pkg/plugin/proto/v1alpha1/rollout.pb.go is excluded by !**/*.pb.go
  • pkg/plugin/proto/v1alpha1/rollout_grpc.pb.go is excluded by !**/*.pb.go
📒 Files selected for processing (1)
  • pkg/plugin/proto/v1alpha1/rollout.proto (1 hunks)
🧰 Additional context used
🪛 Buf (1.59.0)
pkg/plugin/proto/v1alpha1/rollout.proto

12-12: import "k8s.io/apimachinery/pkg/runtime/generated.proto": file does not exist

(COMPILE)

🔇 Additional comments (5)
pkg/plugin/proto/v1alpha1/rollout.proto (5)

98-113: Clarify the intent of field number gap in RolloutResult.

Line 112 defines placement_total_clusters with field number 6, skipping field number 5. This is unusual.

Please confirm:

  • Is field 5 intentionally reserved for future use?
  • If not, consider renumbering to use field 5 sequentially:
-  // placement_total_clusters is the total number of clusters in the placement decision.
-  int32 placement_total_clusters = 6;
+  // placement_total_clusters is the total number of clusters in the placement decision.
+  int32 placement_total_clusters = 5;

Protobuf field numbering should be sequential (or have explicit reserved declarations) to avoid confusion and maintain clarity for future maintainers.


30-35: Terminology in comments is now consistent.

The comments on lines 32–34 correctly reference the SUCCEEDED, INPROGRESS, and FAILED enum values, matching the actual ValidateResponse.Result enum definition at lines 148–163. ✓


46-51: Terminology in comments is now consistent.

The comments on lines 48–50 correctly reference the SUCCEEDED, INPROGRESS, and FAILED enum values, matching the actual ValidateResponse.Result enum definition. This addresses the previous concern about inconsistent terminology.


1-86: API design is well-structured.

The service definition with 8 RPCs and supporting request/response types follows a clear initialization → begin → progress → validate pattern for both rollout and abort workflows. Metadata encapsulation and optional fields enable evolutionary extensibility. The Capabilities message allows plugins to declare supported operations. Overall design is sound for a plugin protocol.


12-12: The import path is valid—the error is a build configuration issue, not a code problem.

Kubernetes' apimachinery provides generated.proto files in its staging area (e.g., staging/src/k8s.io/apimachinery/pkg/runtime/generated.proto), and this import pattern is standard across Kubernetes API definitions.

The static analysis error occurs because:

  • The sandbox environment lacks Kubernetes protobuf source files (not vendor-ed in this repo)
  • Proper build setup requires protoc to be configured with --proto_path entries that include the k8s repo layout so imports resolve correctly

In a properly configured build environment with Kubernetes dependencies available (vendored or via build system configuration), this import will resolve successfully. The k8s.io.apimachinery.pkg.runtime.Unknown type usage is also correct per Kubernetes protobuf standards.

No changes to the proto file are needed.


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 and usage tips.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 2

🧹 Nitpick comments (1)
pkg/plugin/proto/v1alpha1/gen.go (1)

5-8: Consider adding documentation about additional prerequisites.

The installation instructions for the protoc plugins are clear, but consider documenting additional prerequisites:

  1. The protoc compiler itself must be installed
  2. Kubernetes dependencies must be vendored (go mod vendor)
  3. The vendor directory structure must match the import paths

This would help developers successfully generate code on first attempt.

Example enhancement:

// Prerequisites for code generation:
//
// 1. Install the Protocol Buffers compiler (protoc)
//    See: https://grpc.io/docs/protoc-installation/
//
// 2. Install the protoc-gen-go and protoc-gen-go-grpc plugins
//    $ go install google.golang.org/protobuf/cmd/protoc-gen-go@latest
//    $ go install google.golang.org/grpc/cmd/protoc-gen-go-grpc@latest
//
// 3. Ensure dependencies are vendored
//    $ go mod vendor
📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between e3c5205 and e538d72.

⛔ Files ignored due to path filters (2)
  • pkg/plugin/proto/v1alpha1/rollout.pb.go is excluded by !**/*.pb.go
  • pkg/plugin/proto/v1alpha1/rollout_grpc.pb.go is excluded by !**/*.pb.go
📒 Files selected for processing (2)
  • pkg/plugin/proto/v1alpha1/gen.go (1 hunks)
  • pkg/plugin/proto/v1alpha1/rollout.proto (1 hunks)
🧰 Additional context used
🪛 Buf (1.59.0)
pkg/plugin/proto/v1alpha1/rollout.proto

12-12: import "k8s.io/apimachinery/pkg/runtime/generated.proto": file does not exist

(COMPILE)

🔇 Additional comments (5)
pkg/plugin/proto/v1alpha1/rollout.proto (4)

97-113: Verify the field numbering gap in RolloutDetails.

Field numbers jump from 4 (removed) to 6 (placement_total_clusters), skipping field number 5. For a new protobuf definition in an initial commit, this gap is unusual. If field 5 is reserved for future use or was removed during development, consider using the reserved keyword to make the intent explicit:

message RolloutDetails {
  repeated ClusterRolloutStatus completed = 1;
  repeated ClusterRolloutStatus in_progress = 2;
  repeated ClusterRolloutStatus timed_out = 3;
  repeated ClusterRolloutStatus removed = 4;
  reserved 5;  // Reserved for future use or previously removed field
  int32 placement_total_clusters = 6;
}

130-137: Verify the field numbering gap in RolloutPluginRequest.

Field numbers jump from 1 (metadata) to 7 (rollout_details), skipping field numbers 2-6. For a new protobuf definition in an initial commit, this large gap is unusual and may indicate copy-paste from another message or placeholder for future fields. If these fields are reserved for future use or were removed during development, consider using the reserved keyword to document the intent:

message RolloutPluginRequest {
  RolloutMeta metadata = 1;
  reserved 2 to 6;  // Reserved for future use
  optional RolloutDetails rollout_details = 7;
}

139-200: Well-designed message definitions.

The ValidateResponse, MutateManifestWorkRequest, and MutateManifestWorkResponse messages are well-structured with:

  • Proper use of proto3 optional keyword
  • Enum values following convention (UNSPECIFIED = 0)
  • Flexible response handling with oneof for different data types
  • Clear, descriptive comments

The design supports extensibility while maintaining clarity.


12-12: ****

The Kubernetes proto file is correctly imported and available. The file vendor/k8s.io/apimachinery/pkg/runtime/generated.proto exists in the vendor directory at the exact path specified in the import statement at line 12. Protoc compilation will succeed with this import as-is. No action required.

Likely an incorrect or invalid review comment.

pkg/plugin/proto/v1alpha1/gen.go (1)

3-3: No issues found—vendor proto files are properly configured.

The verification confirms that:

  • The vendor directory exists with all required Kubernetes proto files
  • vendor/k8s.io/apimachinery/pkg/runtime/generated.proto is present
  • The relative path ../../../../vendor in the go:generate directive correctly resolves from pkg/plugin/proto/v1alpha1/
  • All proto imports in rollout.proto are satisfied

The code generation setup is already correct and requires no changes.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 0

🧹 Nitpick comments (1)
pkg/plugin/proto/v1alpha1/rollout.proto (1)

98-113: Clarify intentional field number gaps with reserved declarations.

RolloutResult and RolloutPluginRequest have gaps in field numbering (RolloutResult skips field 5, RolloutPluginRequest skips fields 2–6). While proto3 allows this, explicit reserved statements improve maintainability and communicate intent to future developers.

Apply these diffs to clarify field reservations:

 // RolloutResult is the the current result of clusters.
 message RolloutResult {
+  reserved 5;
   // applied is the clusters that have been completed.
   repeated ClusterRolloutStatus applied = 1;
 // RolloutPluginRequest is the request to the rollout plugin.
 message RolloutPluginRequest {
+  reserved 2, 3, 4, 5, 6;
   // metadata is the metadata of the rollout.
   RolloutMeta metadata = 1;

Also applies to: 131-137

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between a177035 and 7effd79.

⛔ Files ignored due to path filters (2)
  • pkg/plugin/proto/v1alpha1/rollout.pb.go is excluded by !**/*.pb.go
  • pkg/plugin/proto/v1alpha1/rollout_grpc.pb.go is excluded by !**/*.pb.go
📒 Files selected for processing (1)
  • pkg/plugin/proto/v1alpha1/rollout.proto (1 hunks)
🧰 Additional context used
🪛 Buf (1.59.0)
pkg/plugin/proto/v1alpha1/rollout.proto

12-12: import "k8s.io/apimachinery/pkg/runtime/generated.proto": file does not exist

(COMPILE)

🔇 Additional comments (3)
pkg/plugin/proto/v1alpha1/rollout.proto (3)

16-57: Service and RPC definitions look well-designed.

The RolloutPluginService RPC methods are clearly documented with appropriate request/response types. The lifecycle pattern (Begin→Progress→Validate for both rollout and rollback, plus MutateManifestWork) is intuitive.


59-206: Message definitions are well-structured and properly documented.

The message types provide clear semantics for request/response payloads, with appropriate use of optional fields, nested enums, and oneof for flexible response data. Naming is consistent and comments are comprehensive.


12-12: ****

The import path is correct and the file exists. The file k8s.io/apimachinery/pkg/runtime/generated.proto is vendored at ./vendor/k8s.io/apimachinery/pkg/runtime/generated.proto and follows standard Kubernetes proto import conventions. This import will compile successfully with the vendored dependency.

Likely an incorrect or invalid review comment.

Copy link
Member

@qiujian16 qiujian16 left a comment

Choose a reason for hiding this comment

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

this should be merged after related proposal is merged at first.
something missing in this is we also need a script for generated file. Update via make update and verify with make verify will be even better.

// MutateManifestWorkResponse is the response to mutate the manifestwork resource before it is applied.
message MutateManifestWorkResponse {
// manifestwork is the mutated manifestwork resource.
k8s.io.apimachinery.pkg.runtime.Unknown manifestwork = 1;
Copy link
Member

Choose a reason for hiding this comment

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

the reason that this is unknown is because there is no proto definition for manifestwork?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants