Remove JSON from config.db #83
No reviewers
Labels
No labels
No milestone
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
Alex/kaido-core!83
Loading…
Reference in a new issue
No description provided.
Delete branch "77-config-db-no-json"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Problem
config.dbstored structured configuration as JSON inbodycolumns, so diffs and merges could not see single fields.factory_profileand theKaido-Journalcommit trailer also held JSON.Change
KeaJSONstays as the only named JSON text exception.recovery_config,/system/recovery,router.recovery).Kaido-Journaluses flat key/value trailers;factory_profilemoved tostate.db.mgmtmapping, QoS capture ordering, nil-safe PUT handlers, section removal in merges, read-only DHCP check on warm start, removal of empty marked firewall tables.go-test-shards.pyplans shards by available workers, so slow packages use all processes.API change
frr.bfdandfrr.ospfare removed.Validation
a56d425d:go test ./...9173 pass, 0 fail, 189 skip;make checkincluding-race, lint, UI and nocgo checks pass;check-config-jsonpasses.make e2e-tomlacceptance: main, variants and api without deviation; JSON audit of four databases without findings.a56d425d:go vetandgo testoninternal/service,internal/stateandinternal/state/historytest; 145 isolated kernel tests with 140 pass, 5 skip, 0 fail.Known limits
check-buildexits 2 on two environment-dependent tests.Findings kept out of this change
config.db; the owner decided to track them separately.Closes #77
🤖 Generated with Claude Code
Revision
f5451bc757ddf9ffee5fa1f6028fd4eaecdde4e6e90357919a0bfbda2fbe790cScope
a56d425d..f5451bc7(2ae344ca,0c7a1f11,9fa06d44,7b7415b4,6c49a608, mergef5451bc7).Findings
Commits in depth
No high or medium findings.
Low: new "never adopted" assertion cannot detect adoption
internal/service/gateway_output_selectors_kernel_test.go:211discards theApplyManagederror beforeassertEmptyDrop(collision).firewallTableMarkerReadertreated an invalid marker as owned, the table would stay in the snapshot,managedFirewallSnapshot(gatewayOutputTableOwned) would return an error, the apply would stop and the assertion would still pass.Earlier findings open without a recorded reason
Each one still holds in the code at this revision. No reason was found in the task notes, this PR or issue #77. Each needs a fix, or a recorded decision or follow-up issue.
High (round 2E H3): a real cold start can open the API early, depending on the wall clock
internal/state/startup.go:144,internal/state/manager.go:1190.interfacesfails there, the retry runs as a warm start.btime, so the retry runs the read-only check instead of an activation.mgmtmapping,startupInterfacesAdoptedthen bypasses the provisioned WAN DHCP gate, although interfaces were never activated in this boot.Medium (round 2 M1, round 2B M2): an absent VPN or RA section leaves runtime state in place
internal/service/appliers.go:656-660,:703-705(WireGuard),:923-927,:959-961(RA).ExtractDesiredreturns nil,Applydoes nothing, and the tunnel or RA keeps running after the configuration dropped it, for example on reverting the commit that created the first entry.withoutFields(internal/drafts/sets.go:93-95) makes the outcome depend on commit order for a merged section removal.Medium (round 2 M4): IFB leftover after a restart during a pending activation
internal/service/qos_transition.go:365,internal/service/qos.go:93-94,:182,:206.a.nativenil ands.managedempty, a source created only by the candidate is not cleaned up, andifb-<vlan>stays with its CAKE root.removeStaleIfbInterfacesis reachable only withscoped=false, and no production caller passes that.50439042fixed the capture ordering, not this path.Medium (round 2B M1): a complete import can leave entries that the imported file does not contain
internal/state/complete_import.go:120,internal/drafts/sets.go:74-98.Checked without findings
f5451bc7: tree identical to the automatic merge of both parents (c88c82ad), so no conflict resolution; the combined diff is empty.0c7a1f11,9fa06d44:markedruns only for otherwise unowned tables, and unreadable or invalid markers stay foreign. Removing the connection release leaks nothing, becauseFreshConndoes not request a lasting socket andCloseLastingis a no-op there.2ae344ca: filters only the reserved generated table.7b7415b4: covers the earlier gap (the DHCP check beside amgmtmapping); warning, repair count and repair result are asserted, including the applier without a DHCP check.6c49a608, shards:rest[index::count]partitions all non-serial tests, and the serial kernel/integration group stays one appended process. BelowSHARD_MIN_TESTSthe package stays one process, as before.6c49a608, split tests: the three tests use the same three pair generators as the former merged map, with the same per-pair assertions, so all former pairs stay covered.a56d425d), whose commit message records the reason.Validation limits
a56d425d(full run) and post-a56d425d package and kernel runs as stated in the PR description. I did not verify those results or any run at this exact head.Revision
766bb20fe8f9eafd90538bef1f81b51542a1c7b4cfb2fc64c4fb698b3663e5bef5451bc7..766bb20f(one test file). Rest of the branch: only the status of the findings from review 42.Findings
No new high, medium or low findings.
Low finding from review 42: addressed
internal/service/gateway_output_selectors_kernel_test.go:206-220now asserts the refusal and the warning instead of discarding the error.ApplyManagedreachesrefreshGatewayOutputMapsLocked(firewall.go:577), which checks all kernel tables throughgatewayOutputTableOwned, and an invalid marker returns the asserted error. This also explains why the suggestion in review 42 (assert that the apply succeeds) did not apply.assertEmptyDrop.firewallTableMarkerReader, using a fresh service with its own log buffer.managedFirewallSnapshotrefuses with the same error and the table stays.Earlier findings: recorded, out of scope by owner decision
startup.go:144,manager.go:1190.appliers.go:656-660,:703-705,:923-927,:959-961. It does not repeat the commit-order note onwithoutFields; this omits a detail and does not misstate the defect.qos_transition.go:365,qos.go:206.Validation limits