feat(agent): enable service.profilesSupport feature gate by default - #2274
Open
royrajan13 wants to merge 1 commit into
Open
feat(agent): enable service.profilesSupport feature gate by default#2274royrajan13 wants to merge 1 commit into
royrajan13 wants to merge 1 commit into
Conversation
Profiles pipelines are gated behind the collector's alpha
service.profilesSupport feature gate, so a profiles pipeline currently fails
agent startup outright:
pipeline "profiles": profiling signal support is at alpha level, gated
under the "service.profilesSupport" feature gate
The agent builds the collector's argv itself and only passes --config, so an
operator has no supported way to enable the gate. It now requests the gate
when building those args, which is what makes profiles usable out of the box.
The request is guarded by a lookup in the collector's feature gate registry.
featuregate.Registry.Set rejects an unknown gate ID (and rejects enabling a
deprecated one), and that error surfaces as a cobra flag parse failure, i.e.
a fatal startup error. Since this gate is on a graduation path and will
eventually be deleted upstream, passing it unconditionally would turn a
routine collector dependency bump into an agent that refuses to start.
Consulting the registry first makes graduation a no-op instead.
Key files:
- cmd/amazon-cloudwatch-agent/featuregates.go: collectorFeatureGateArgs
builds the --feature-gates arg, skipping any gate the registry cannot
enable.
- cmd/amazon-cloudwatch-agent/amazon-cloudwatch-agent.go: appends those args
alongside the existing --config args in runAgent.
Testing:
- New unit tests cover all four registry states: gate registered (arg
emitted), absent (nil, no error), stable (still enableable, arg emitted),
and deprecated (treated like absent). The produced args are parsed through
the real featuregate flag set rather than string-compared, and one test
asserts the gate ends up enabled after parsing.
- go build ./..., CGO_ENABLED=0 go test ./cmd/amazon-cloudwatch-agent/,
make fmt and make fmt-sh all pass.
Closes aws#2273
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description of the issue
Issue: #2273
Configuring a profiles pipeline makes the agent fail to start, because the
collector's profiles signal is gated behind
service.profilesSupport(alpha, offby default in collector v0.124.0):
The agent builds the collector's arguments itself and only ever passes
--config=, so an operator has no supported way to enable the gate.Description of changes
The agent now appends
--feature-gates=+service.profilesSupportto the argumentsit builds for the collector command, so profiles pipelines start without the
operator needing to know the gate exists.
The flag is only appended after checking the collector's feature-gate registry
for an enableable gate with that ID.
featuregate.Registry.Setreturns an errorfor an unknown gate ID, which surfaces as a flag-parse failure and a fatal
startup error. Without the guard, the moment the gate graduates and is deleted
upstream, a routine collector dependency bump would produce an agent that
refuses to start. With it, graduation is a no-op.
The guard also treats
StageDeprecatedas not enableable, becauseSetrejectsenabling a deprecated gate with the same class of error, and deprecated is the
pre-deletion state of a graduating gate. A
StageStablegate that is stillregistered remains enableable, so the flag keeps being passed until the gate is
removed from the registry entirely.
New file
cmd/amazon-cloudwatch-agent/featuregates.goholdscollectorFeatureGateArgsand the registry check.amazon-cloudwatch-agent.gogains one line at the existing
cmd.SetArgssite.featuregatemoves from theindirect to the direct require block in
go.mod(no version change).License
By submitting this pull request, I confirm that you can use, modify, copy, and
redistribute this contribution, under the terms of your choice.
Tests
New unit tests in
cmd/amazon-cloudwatch-agent/featuregates_test.gocover allfour registry states: gate registered at alpha (flag passed), gate at stable
(flag still passed), gate absent (no flag, no error), and gate deprecated (no
flag, no error).
Rather than string-comparing the produced arguments, each case parses them
through a real
featuregateregistry flag set, and a separate test asserts thegate actually flips to enabled -- so the tests validate the flag name and
+syntax against the library rather than against a hardcoded expectation.
go build ./...-- passgo test ./cmd/amazon-cloudwatch-agent/-- pass (whole package)make fmt-- pass, no changesmake fmt-sh-- pass, no changesRequirements
make fmtandmake fmt-sh-- run, both cleanmake lint-- run; it reports pre-existing repo-wide findings and exitsnon-zero on unmodified
mainas well. None of the findings are in the newfile, and none are on either line added to
amazon-cloudwatch-agent.go.