fix(manifest): parse flow-style YAML maps instead of dropping them#69
Merged
Conversation
A flow-style map value like limits: { cpu: "1", memory: 512Mi } was
parsed as a scalar string, so getMap returned nil and the container's
resources were silently zero — the pod was admitted with no accounting,
reopening the overcommit class from #43 for any manifest written in
flow style. Found live during #53 verification: the flow-style pod ran
with allocated 0/0 while its block-style twin allocated 1000/512.
parseFlowMap joins parseFlowList on a shared depth-aware item splitter;
flow lists now support nested collections instead of erroring, flow
maps work as map values and list items, and a malformed flow collection
fails the manifest with a 400 rather than becoming a silent default.
Closes #66
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
1 participant
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.
Problem (#66)
The parser handled flow-style lists but not flow-style maps:
limits: { cpu: "1", memory: 512Mi }became a scalar string,getMapreturned nil, and the pod was admitted with zero requests — the #43 overcommit class through yet another door. Live evidence during #53 verification: the flow-style pod ran withallocated: 0/0; its block-style twin allocated 1000/512.Fix
parseFlowMap+ shared depth-awaresplitFlowItems;parseFlowListnow supports nested collections (previously an error).- { name: FOO, value: bar }), and nested ({ limits: { cpu: "2" } }). Values with colons (image: docker.io/x:latest, quoted strings) handled via a top-level-colon separator.400 Bad Request— the fourth instance of the silent-default class (Admission control overcommits memory: second 100Gi-request pod admitted while first still running; unified-memory host hard-freezes (NVRM NV_ERR_NO_MEMORY) #43 quantities, YAML block-scalar container command is collapsed to one line before podman run #44 block scalars, PodStatus maps podman 'Degraded' state to {Running: false, ExitCode: 0} — partially-crashed pods are marked Completed #52 pod states), so the devlog now records the pattern as a standing rule.Testing
Unit: flow map basics, empty, nesting, colon-bearing values, malformed inputs, nested flow lists, flow map as list item. End-to-end: the live repro (flow-style limits → 1000m/512MB accounted), the #42 runbook shape, malformed map → parse error. Full suite
-racegreen, vet + staticcheck clean.Live acceptance after deploy: the exact #66 repro manifest must show
allocated: {cpuMillis: 1000, memoryMB: 512}.Closes #66