chore(agent-data-plane, config): hand back dynamic configuration tasks instead of spawning them - #2712
Conversation
This stack of pull requests is managed by Graphite. Learn more about stacking. |
Binary Size Analysis (Agent Data Plane)Baseline: 9e63899 · Comparison: a8ad16e · diff ✅ Binary size difference within thresholdChanges by Module
Detailed Symbol Changes |
Regression Detector (Agent Data Plane)Run ID: Optimization Goals: ✅ No significant changes detectedFine details of change detection per experiment (5)Experiments configured
Bounds Checks: ✅ Passed (5)
ExplanationA change is flagged as a regression when |Δ mean %| > 5.00% in the regressing direction for its optimization goal AND SMP marks the experiment as a regression ( |
9dc9752 to
606ceff
Compare
af35828 to
a241623
Compare
a241623 to
ff1bac3
Compare
There was a problem hiding this comment.
ff1bac3 to
559d57d
Compare
webern
left a comment
There was a problem hiding this comment.
I added Closes #2196 to your PR description because I think it does. You could change it to Progresses or Related if I'm wrong.
We have a fairly ugly collision here with #2688, so I hate approving this 😅 . Fortunately LLMs excel at cleaning of a rebase disaster.
There was a problem hiding this comment.
Just an FYI, but I'm trying to build a "crazy config stuff from the agent" test rig and I think it's about time to retire the "smoke tests" and registry. Should happen soon, the "crazy config stuff from the agent" test rig is a bit unwieldy in the repo. It's draft is at #2717. And they don't do the same thing, exactly, but anyway I think the smoke tests are useless now and I haven't forgotten about removing this stuff.
559d57d to
49c9d64
Compare
…s instead of spawning them
49c9d64 to
a8ad16e
Compare
…s instead of spawning them (#2712) ## Summary This PR updates our configuration primitives to move most of the the background tasks/asynchronicity to `agent-data-plane-config-system` where we can wire it up to participate in supervision. Prior to this PR, the background work to update a configuration dynamically, as well as get dynamic updates from some arbitrary spot (like the remote agent client) _into_ the configuration was split across two places, one of those being `saluki-config`. In our quest to push background talks into supervision _without_ having to have `saluki-config`, this PR moves the majority of this work into `agent-data-plane-config-system` where it can get the proper `Supervisable` treatment. What remains in `saluki-config` is a _very_ thin layer -- one meant simply to facilitate integrating the given updates into the resolved configuration -- which is then driven by the supervised task. Admittedly, it's not the most satisfying or holistic split, but it moves things in the right direction prior to fully introducing supervision "scopes", and subsequent stacked PRs will be able to improve this situation. ## Change Type - [ ] Bug fix - [ ] New feature - [x] Non-functional (chore, refactoring, docs) - [ ] Performance ## How did you test this PR? Existing and new tests: ensuring the supervised worker keeps driving the processing of configuration updates as long as the update channel is available, etc. ## References - Closes #2196 DADP-2 a64abc8

Summary
This PR updates our configuration primitives to move most of the the background tasks/asynchronicity to
agent-data-plane-config-systemwhere we can wire it up to participate in supervision.Prior to this PR, the background work to update a configuration dynamically, as well as get dynamic updates from some arbitrary spot (like the remote agent client) into the configuration was split across two places, one of those being
saluki-config. In our quest to push background talks into supervision without having to havesaluki-config, this PR moves the majority of this work intoagent-data-plane-config-systemwhere it can get the properSupervisabletreatment. What remains insaluki-configis a very thin layer -- one meant simply to facilitate integrating the given updates into the resolved configuration -- which is then driven by the supervised task.Admittedly, it's not the most satisfying or holistic split, but it moves things in the right direction prior to fully introducing supervision "scopes", and subsequent stacked PRs will be able to improve this situation.
Change Type
How did you test this PR?
Existing and new tests: ensuring the supervised worker keeps driving the processing of configuration updates as long as the update channel is available, etc.
References
DADP-2