Proto: console pipeline api tiers #1417
Conversation
|
The latest Buf updates on your PR. Results from workflow Buf CI / push-module (pull_request).
|
| import "redpanda/api/dataplane/v1alpha2/pipeline.proto"; | ||
|
|
||
| // RedpandaConnectTier is the tier of the pipeline. | ||
| enum RedpandaConnectTier { |
There was a problem hiding this comment.
Would PipelineTier be more accurate? Are we going to re-use tiers for non-RP Cloud?
| (buf.validate.field).required = true | ||
| ]; | ||
|
|
||
| // custom |
There was a problem hiding this comment.
Not sure this comment is meant to be here
| ]; | ||
|
|
||
| // custom | ||
| RedpandaConnectTier tier = 4; |
There was a problem hiding this comment.
Additional validation annotations should probably be used here to enforce users to specify a tier
| // The pro tier. | ||
| REDPANDA_CONNECT_TIER_PRO = 3; | ||
| // The custom tier. | ||
| REDPANDA_CONNECT_TIER_CUSTOM = 4; |
There was a problem hiding this comment.
What happens if someone uses TIER_CUSTOM? There are no additional properties to specify the "custom" part of this I believe
There was a problem hiding this comment.
The plan is that only frontend will use tiering, and in the Console version the tier will map to predefined resource requests and limits. The Dataplane API will still use granular requests and limits for resources. since those will not necessarily map to predefined values, we have to categorize them somehow to a tier... so the idea was to use a "custom" enum for that...
There was a problem hiding this comment.
Okay got you, I think we can make that clear by adding behaviour annotations and make that a read-only flag plus adding validation annotations on the request message so that this option cannot be selected
Initial attempt to introduce "tiers" to the Console version of Pipeline API.
Where relevant requests and responses are now based on their dataplane versions, with resource parameters substituted with the limit.