[
https://issues.apache.org/jira/browse/FLINK-41304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis-Mircea Ciupitu updated FLINK-41304:
------------------------------------------
Description:
h1. Motivation
The canary label ({{{}flink.apache.org/canary: "true"{}}}) is handled
inconsistently across the operator resource kinds:
* {{FlinkDeployment}} and {{FlinkSessionJob}} canaries are supported and
checked by the health probe.
* {{FlinkStateSnapshot}} has no canary handling in its controller, so the
label is ignored and the resource is reconciled as a regular snapshot. The
validation webhook still skips every canary-labelled resource, so an invalid
canary-labelled snapshot is accepted on creation and only rejected later by the
operator's own validation.
* {{FlinkBlueGreenDeployment}} has no canary handling either, so the label is
silently ignored and the resource is reconciled as a regular blue/green
deployment.
All controllers share the same reconciliation thread pool, so a single canary
kind already verifies that the operator picks up and reconciles spec changes in
time.
A canary of another kind only adds checks on that kind’s informers and event
processing, which the operator’s health check mechanism already provides
regardless of canaries.
{{FlinkDeployment}} is the central resource of the operator, so canaries only
need to be supported on that kind.
h1. Proposal
To unify the canary approach and limit it to detecting JOSDK reconciliation
slowdowns:
* Canary resources are supported on {{FlinkDeployment}} only.
* {{FlinkSessionJob}} canaries keep working but are deprecated, with a warning
log, and are planned to be handled like the other kinds in a later release.
* Canary-labelled {{FlinkStateSnapshot}} and {{FlinkBlueGreenDeployment}}
resources are not reconciled, and a warning explains that canaries must be
{{FlinkDeployment}} resources.
* The validation webhook only skips the validation of supported canary kinds.
* The health documentation is updated accordingly.
was:
h1. Motivation
The canary label ({{{}flink.apache.org/canary: "true"{}}}) is handled
inconsistently across the operator resource kinds:
* {{FlinkDeployment}} and {{FlinkSessionJob}} canaries are supported and
checked by the health probe.
* {{FlinkStateSnapshot}} has no canary handling in its controller, so the
label is ignored and the resource is reconciled as a regular snapshot. The
validation webhook still skips every canary-labelled resource, so an invalid
canary-labelled snapshot is accepted on creation and only rejected later by the
operator's own validation.
* {{FlinkBlueGreenDeployment}} has no canary handling either, so the label is
silently ignored and the resource is reconciled as a regular blue/green
deployment.
All controllers share the same reconciliation thread pool, so a single canary
kind already verifies that the operator picks up and reconciles spec changes in
time.
A canary of another kind only adds checks on that kind’s informers and event
processing, which the operator’s health check mechanism already provides
regardless of canaries.
{{FlinkDeployment}} is the central resource of the operator, so canaries only
need to be supported on that kind.
h1. Proposal
To unify the canary approach and limit it to detecting JOSDK reconciliation
slowdowns:
* Canary resources are supported on {{FlinkDeployment}} only.
* {{FlinkSessionJob}} canaries keep working but are deprecated, with a warning
log, and are planned to be handled like the other kinds in a later release.
* Canary-labelled {{FlinkStateSnapshot}} and {{FlinkBlueGreenDeployment}}
resources are not reconciled, and a warning explains that canaries must be
{{FlinkDeployment}} resources.
* The validation webhook only skips the validation of supported canary kinds.
* The health documentation is updated accordingly.
> Support canary resources on FlinkDeployment only
> ------------------------------------------------
>
> Key: FLINK-41304
> URL: https://issues.apache.org/jira/browse/FLINK-41304
> Project: Flink
> Issue Type: Improvement
> Components: Kubernetes Operator
> Reporter: Dennis-Mircea Ciupitu
> Priority: Major
>
> h1. Motivation
> The canary label ({{{}flink.apache.org/canary: "true"{}}}) is handled
> inconsistently across the operator resource kinds:
> * {{FlinkDeployment}} and {{FlinkSessionJob}} canaries are supported and
> checked by the health probe.
> * {{FlinkStateSnapshot}} has no canary handling in its controller, so the
> label is ignored and the resource is reconciled as a regular snapshot. The
> validation webhook still skips every canary-labelled resource, so an invalid
> canary-labelled snapshot is accepted on creation and only rejected later by
> the operator's own validation.
> * {{FlinkBlueGreenDeployment}} has no canary handling either, so the label
> is silently ignored and the resource is reconciled as a regular blue/green
> deployment.
> All controllers share the same reconciliation thread pool, so a single canary
> kind already verifies that the operator picks up and reconciles spec changes
> in time.
> A canary of another kind only adds checks on that kind’s informers and event
> processing, which the operator’s health check mechanism already provides
> regardless of canaries.
> {{FlinkDeployment}} is the central resource of the operator, so canaries only
> need to be supported on that kind.
> h1. Proposal
> To unify the canary approach and limit it to detecting JOSDK reconciliation
> slowdowns:
> * Canary resources are supported on {{FlinkDeployment}} only.
> * {{FlinkSessionJob}} canaries keep working but are deprecated, with a
> warning log, and are planned to be handled like the other kinds in a later
> release.
> * Canary-labelled {{FlinkStateSnapshot}} and {{FlinkBlueGreenDeployment}}
> resources are not reconciled, and a warning explains that canaries must be
> {{FlinkDeployment}} resources.
> * The validation webhook only skips the validation of supported canary kinds.
> * The health documentation is updated accordingly.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
