Conversation
…sting on one other than the first - previously it was assumed the profilers would be created on the first instance of a remote to a system - if a profiler is created on a remote that doesn't have any other engines and it is not the first instance of that remote then that remote would not end up with any engines attached to and crash the endpoint - ensure that only one profiler is specified and find which remote it is one and use it to avoid this bug
- the available modes are 'auto' (the default and what we currently have where tools are deployed everywhere), 'opt-in' (an endpoint has to be specifically configured to deploy the tool by "opting in"), 'opt-out' (an endpoint can be configured to disable the tool by "opting out") - when 'opt-in' or 'opt-out' are chosen a tag is specified which is used to identify the tool(s) that is being used or not used
- this allows tool opt-in/opt-out requests to be made at an endpoint wide level -- this means you can use the opt-in and opt-out functionality to either disable or enable a tool on all profiled cluster nodes
…n't try to create profiler pods
…/opt-out - previously this was only possibly at the endpoint level which meant the settings affected all aspects of the endpoint. this degree of control continues on as scope==endpoint - a new level of control is being defined which is scope=engine. in this mode tools can be specified as opt-in or opt-out relative to one or more engines. what this means is that if a specific engine (<role>-<id>) is configured to opt-in to a specific tool that tool will be enabled on the node where that engine is provisioned, similarly if an engine is configured to opt-out of a tool that tool will not be enabled on the node where that engine is provisioned since this can be configured on a per-engine basis and there is the potential for many engines to be provisioned on many nodes there is going to be a fair amount of complexity in determining what the final tool configuration actually is. for example, if a node ends up having no tools deployed on it then when need to be sure that we don't actually build a tool pod for that node.
Implement 'endpoint' and 'engine' scopes for tool deployment. The 'endpoint' scope applies tool opt-in/opt-out uniformly across all nodes. The 'engine' scope allows per-engine tag control, aggregating tags by node so each node gets its own tool list based on the engines running on it. Nodes with no tools to deploy are skipped entirely. Introduces determine_tools_for_node() to centralize the opt-in/opt-out tag evaluation logic, and extends create_pod_crd() with a node_tools parameter to filter profiler containers per node. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
atheurer
approved these changes
Feb 27, 2026
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
2 participants
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.
No description provided.