Repository navigation
fix(bootstrap): put the setup-request gate behind a setting that defaults off - #50
Merged
Merged
Conversation
…ults off A fresh bootstrap waited at the setup-request pause forever, because the console can't issue a setup request ID until dmf-infra deploys its setup-request support. Add DMF_SETUP_REQUEST_GATE (Settings.setup_request_gate), default off. With it off, configure runs before the workstation pause, with no first-passkey pause, no setup-request pause and no ID requirement, and the resume route rejects both gate pauses. With it on, the pauses, the ID requirement, the server-side passkey check and the redaction behave as before. Fresh runs and retries from disk read the same setting. Turn the default on when the dmf-infra support lands. Closes dmfdeploy/dmfdeploy#844 Signed-off-by: znerol2 <6800371+znerol2@users.noreply.github.com>
…te mode A retry inserts steps ahead of its target. When one of them failed, the journal recorded the step after it, so a restart with the setup-request gate in the other mode could slice past configure and report success without configuring. Keep the original retry target when an inserted step fails, record the steps that completed, and refuse a workstation cursor when configure is not recorded as complete. Document that a run waiting at a gate pause does not survive a container restart. Refs dmfdeploy/dmfdeploy#844 Signed-off-by: znerol2 <6800371+znerol2@users.noreply.github.com>
…hanges The step order depends on the gate setting, so slicing a graph at a cursor written under the other setting can skip a step that never completed. The resume journal now records the gate setting the run was built with. A retry from disk, or from a run still in memory, is refused with 409 when the recorded setting differs from the current one or is missing or not a JSON boolean. Retries in the same setting behave as before. This replaces the retry-target and completed-step bookkeeping, which let completion evidence carry across runs. Refs dmfdeploy/dmfdeploy#844 Signed-off-by: znerol2 <6800371+znerol2@users.noreply.github.com>
4 tasks
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.
Summary
Since 89d9bb1, a fresh bootstrap pauses before
configureand waits, with no timeout, for a setup request ID that the operator creates in the DMF Console. The console can only create that ID once dmf-infra deploys its setup-request support, which is still in the draft dmfdeploy/dmf-infra#118 and #119. A bootstrap frommaintherefore stalls.This PR puts the gate behind a setting that defaults off:
DMF_SETUP_REQUEST_GATEenvironment variable maps toSettings.setup_request_gateand is off by default. It follows the same pattern asDMF_TLS_ENABLED.initial-passkeypause nor thesetup-requestpause runs, and no ID is required. The order is configure, then workstation, then passkey, as it was before 89d9bb1. The resume route returns 409 for both gate pauses, and retry from disk doesn't add them back.initial-passkeyis gated too. It arrived with the same commit and exists only so the operator can sign in to the console and create the ID. Thepasskeypause after configure stays either way.The README gets a short note saying the gate stays off until the dmf-infra setup-request support lands.
Follow-up
The change that lands dmfdeploy/dmf-infra#118 and #119 turns this default on.
bin/dmf-initdoesn't forward the variable yet; until then, pass it withdocker -e.Tests
tests/test_setup_request_gate.py, 9 tests. It covers the setting, the step graph with the gate on and off, a fresh run, retry from disk, and the resume route. All 9 fail onmain. When the default is set to on, the 3 default-off tests fail.pytest: 146 passed, 2 skipped.ruffreports no issues.Closes dmfdeploy/dmfdeploy#844