Repository navigation
Conversation
The extra-compatible-node-models flag is only reachable through LaunchDarkly, so self-hosted deployments (no LaunchDarkly, offline ldtestdata store) cannot configure it and the cross-CPU placement feature it gates is unusable for heterogeneous-CPU fleets. Add an EXTRA_COMPATIBLE_NODE_MODELS env fallback, mirroring DEFAULT_FIRECRACKER_VERSIONS: a malformed value fails NewClient fast via extraCompatibleNodeModelsEnvErr. LaunchDarkly, where present, still overrides it. Refs e2b-dev#3764
This branch has not been deployed
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
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.
What
Add an
EXTRA_COMPATIBLE_NODE_MODELSenvironment-variable fallback for theextra-compatible-node-modelsflag, so deployments without LaunchDarkly can configure cross-CPU-model placement.Refs #3764.
Why
extra-compatible-node-modelsis declared with a null fallback and no env override:Without
LAUNCH_DARKLY_API_KEY,NewClientfalls back to theldtestdataoffline store, which is only seeded by each flag's construction-time fallback. With the fallback fixed atldvalue.Null(),GetExtraCompatibleNodeModelsalways returnsnil, soIsCompatibleWithExtradegrades to the hardcoded table and the flag can never carry a value. Self-hosted clusters with a heterogeneous (but compatible) CPU fleet therefore cannot enable the feature at all.How
Give the flag an env-sourced fallback, consistent with how the same file already bridges the no-LaunchDarkly case for
firecracker-versions(DEFAULT_FIRECRACKER_VERSIONS),build-firecracker-version,build-kernel-version, andbuild-envd-version:EXTRA_COMPATIBLE_NODE_MODELSenv var — a JSON object of build model to node models, e.g.{"106":["173"]}.NewClientfast viaextraCompatibleNodeModelsEnvErr(same discipline asFirecrackerVersionsFallback), rather than being silently dropped.The one-way, same-architecture-and-family compatibility rule in
IsCompatibleWithExtrais unchanged; this only changes where the value can come from, not the rule. Operators remain responsible for choosing safe (older-build → newer-node) pairs, exactly as with LaunchDarkly today.Test
TestParseExtraCompatibleNodeModelscovers empty/whitespace (null, no error), a valid object (parses to the flag value and is read back byGetExtraCompatibleNodeModels), and malformed JSON (errors, stays null).