You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
# One of 'breaking', 'deprecation', 'new_component', 'enhancement', 'bug_fix'
2
+
change_type: enhancement
3
+
4
+
# The name of the component, or a single word describing the area of concern, (e.g. collector, target allocator, auto-instrumentation, opamp, github action)
5
+
component: collector
6
+
7
+
# A brief description of the change. Surround your text with quotes ("") if it needs to start with a backtick (`).
8
+
note: Keep multiple previous versions of the Collector ConfigMap, configurable via the ConfigVersions field.
9
+
10
+
# One or more tracking issues related to the change
11
+
issues: [2871]
12
+
13
+
# (Optional) One or more lines of additional information to render under the primary note.
14
+
# These lines will be padded with 2 spaces and then inserted directly into the document.
15
+
# Use pipe (|) for multiline entries.
16
+
subtext: |
17
+
This change introduces a new field in the Collector ConfigMap, `ConfigVersions`, which allows users to specify the number of previous versions of the Collector ConfigMap to keep. The default value is 1, which means that the current and one previous version of the Collector ConfigMap are kept. By keeping historical versions of the configuration, we ensure that during a config upgrade the previous configuration is still available for running (non-upgraded) pods as well as for rollbacks. If we overwrite the original ConfigMap with the new configuration, any pod which restarts for any reason will get the new configuration, which makes rollouts impossible to control.
0 commit comments