Skip to content

Enable distributed runners by default#971

Open
phinze wants to merge 1 commit into
mainfrom
phinze/mir-955-ga-enable-distributed-runners-by-default-keep-labs-flag-as
Open

Enable distributed runners by default#971
phinze wants to merge 1 commit into
mainfrom
phinze/mir-955-ga-enable-distributed-runners-by-default-keep-labs-flag-as

Conversation

@phinze

@phinze phinze commented Jul 24, 2026

Copy link
Copy Markdown
Contributor

Distributed runners have been living behind the --labs distributedrunners opt-in while they baked. They've held up, so this makes them the default for everyone: one line in features.yaml (regenerated into labs.gen.go) flipping the distributedrunners default to on. Because IsEnabled falls back to the feature default whenever a flag isn't explicitly set, that single change lights up all three gates at once: the runner command tree registers in the CLI, embedded etcd comes up with the mTLS config remote runners need, and the scheduler takes the distributed path.

The labs flag isn't going anywhere, it's now the escape hatch instead of the opt-in. An operator who sees trouble can force the old behavior back with MIREN_LABS=-distributedrunners (the parser already understood the - disable prefix, so no new code was needed). Ripping out the flag and gating is deliberately a later step (MIR-1461), so we keep a clean fallback for at least one release.

Worth calling out why this lands now rather than earlier: verifying the flip surfaced two migration hazards the original bake never exercised, and both were fixed first (#964, #965). Enabling the flag flips embedded etcd from plaintext to TLS, and fresh installs needed the CA created before that setup runs, while an existing cluster whose previous shutdown was unclean would wedge on the plain→TLS container recreate. With those in, I verified the full unclean-shutdown migration in a dev cluster: crash a plaintext-etcd server, boot with the flag on, and it now tears down the orphaned container and comes back up on mTLS etcd cleanly instead of dying on "snapshot already exists."

The only other change here is a small test asserting distributed runners are on with no flags set, so a future regeneration can't quietly undo it.

Closes MIR-955

Distributed runners have baked long enough to graduate from the labs
opt-in. Flip the distributedrunners feature default to on, so every
cluster gets the distributed scheduler path (plus the runner command
tree and etcd mTLS) without --labs distributedrunners.

The labs flag stays as an escape hatch: an operator who sees badness can
force the old path back with MIREN_LABS=-distributedrunners. The parser
already handles the "-" disable prefix, so this is just a default flip
plus a regression guard so it can't silently revert.
@coderabbitai

coderabbitai Bot commented Jul 24, 2026

Copy link
Copy Markdown

Review Change Stack

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: d63be748-d93c-4dd1-912c-9571042e3010

📥 Commits

Reviewing files that changed from the base of the PR and between 2689e86 and 705fdef.

📒 Files selected for processing (3)
  • pkg/labs/features.yaml
  • pkg/labs/labs.gen.go
  • pkg/labs/labs_test.go

📝 Walkthrough

Walkthrough

The distributedrunners lab feature is changed from disabled to enabled by default in its configuration and generated defaults. A test resets lab state, initializes it without feature flags, and verifies that DistributedRunners() returns true.


Comment @coderabbitai help to get the list of available commands.

@miren-code-agent miren-code-agent Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🍪 biscuit: ✅ ready to merge — auto-review, non-blocking

This is a focused, intentional GA promotion: flip distributedrunners from falsetrue in both the canonical source-of-truth (features.yaml) and the generated file (labs.gen.go), and add a test that pins that expectation. I read through all three files and the surrounding call sites before reaching a verdict.

The change is correct. The IsEnabled path in labs.gen.go (lines 118–124) has a two-tier lookup: first the enabledFeatures map, then featureDefaults. This means the new default takes effect even in the CLI path (cli.go) where labs.Init is only called when MIREN_LABS is non-empty — DistributedRunners() will correctly return true without an explicit Init, because the fallback reads straight from featureDefaults. I confirmed this explicitly.

The test is meaningful. TestDistributedRunnersEnabledByDefault calls Reset() to clear any prior state, then Init(nil, nil) with no flags, and asserts DistributedRunners() returns true. That's exactly the path a fresh server startup takes when no MIREN_LABS env var is set.

Existing disablement still works. The Init flag parser still accepts -distributedrunners (and -all) to let operators opt out. The existing tests (TestAllKeywordWithExclusion, TestNegativeAllDisablesAll) cover this. Nothing in the PR touches that logic.

One small observation worth flagging: the .iso/peers.yml fixture and CLAUDE.md both still configure MIREN_LABS=distributedrunners explicitly to opt the test environment in. With the feature now on by default, those explicit flags are a no-op rather than wrong — but they create mild noise by implying the feature still needs opting in. This is purely cosmetic and doesn't affect correctness, so I'm not blocking on it.

This is a clean, well-scoped GA graduation. Ready to graduate to human review (noting it's still a draft).


🍪 full review note · comment /biscuit review to run biscuit again.

Inline comments

.iso/peers.yml:15

Now that distributedrunners is on by default, MIREN_LABS=distributedrunners here is a no-op rather than wrong. Worth removing so the file doesn't imply the feature still needs an explicit opt-in — but this isn't a blocker.

@phinze
phinze marked this pull request as ready for review July 24, 2026 18:13
@phinze
phinze requested a review from a team as a code owner July 24, 2026 18:13
@phinze phinze mentioned this pull request Jul 24, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants