Skip to content

[opentelemetry-collector]: custom apiVersion support#2050

Open
medzin wants to merge 7 commits intoopen-telemetry:mainfrom
medzin:main
Open

[opentelemetry-collector]: custom apiVersion support#2050
medzin wants to merge 7 commits intoopen-telemetry:mainfrom
medzin:main

Conversation

@medzin
Copy link
Copy Markdown

@medzin medzin commented Jan 26, 2026

Adds configurable apiVersion and extra updateStrategy fields for DaemonSet/StatefulSet/Deployment mode. This enables:

  • Using custom controllers like OpenKruise Advanced DaemonSet and Advanced StatefulSet
  • Partition-based rollouts for safer canary deployments
  • In-place pod updates without recreation
  • Testing new API versions before they become stable

Includes example and CI values for OpenKruise configuration.

Adds configurable apiVersion and extra updateStrategy fields for
DaemonSet mode. This enables:

- Using custom controllers like OpenKruise Advanced DaemonSet
- Partition-based rollouts for safer canary deployments
- In-place pod updates without recreation
- Testing new API versions before they become stable

Includes example and CI values for OpenKruise configuration.
@medzin medzin requested review from a team, TylerHelmuth, dmitryax and povilasv as code owners January 26, 2026 10:44
whenDeleted: Retain
whenScaled: Retain

daemonset:
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Do we need this nested under a daemonset section? Would it be applicable to other modes?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

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

In case of OpenKruise the same trick would work for StatefulSet but not for Deployment so I can add support for StatefulSet under a separate key like statefulset or we can move apiVersion to a top level variable and just fail when using a Deployment.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Is it ever valid to have mode="deployment" and to set an API? If so, a root-level field would be nice.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

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

Theoretically, if apps/v2 were to be released someday, it would allow for quick testing to see if the chart would work in its current state. However, at the moment, I don't know of a use case for it.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

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

@TylerHelmuth so should I just move it to the top level? The use case for mode="deployment" is a stretch but the code will be cleaner :)

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

I think top level apiVersion is the most future-proof solution.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

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

@TylerHelmuth ok moved the variable to top level and added examples for other modes.

medzin added 4 commits March 21, 2026 11:51
Move .Values.daemonset.apiVersion to .Values.apiVersion so it applies
uniformly to daemonset, deployment, and statefulset modes.
@medzin medzin changed the title [opentelemetry-collector]: custom DaemonSet support [opentelemetry-collector]: custom apiVersion support Mar 21, 2026
@medzin medzin requested a review from TylerHelmuth March 31, 2026 13:18
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