Repository navigation
Report a local machine's image now that smolvm 1.16.1 puts it on the wire - #1
Merged
Merged
Conversation
…efault dcc671a moved both egress defaults to blocked and wrote the comment that explains it, but left the earlier comment above it. The dead lines still say run-once defaults to "open" on local, which is the opposite of the value on the line below them and of the README's own table. Comment only; no default changes.
smolvm v1.16.1 (smol-machines/smolvm#1262) puts the resolved workload image on the local API's machine responses. Until now localView hardcoded null, because the API had nothing to read, so list-machines and get-machine on the local target said nothing about what a machine was running and two machines built from different images looked identical to a caller. The field is optional and nullable in the spec, so an older serve that omits it and a machine that has no image both still read as null.
The tools table names the field and the release that made it readable, the Verified section records the 1.16.1 re-run that established it on macOS, and a Changelog section carries the unreleased line so cutting the next version is one command. No version bump.
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.
smolvm 1.16.1 puts a machine's resolved workload image on the local API's
machine responses. This server had no way to read one before, so
localViewreturned a hardcoded null and every local machine looked the same.
What a caller saw before:
get-machineandlist-machineson the localtarget returned
"image": nullfor every machine, whatever it was builtfrom. Two machines running different images were indistinguishable in the
tool output, and an agent that wanted to know what it was working inside had
to have remembered the create call. The cloud target already reported the
image, so the same tool answered the question on one fleet and not the other.
What a caller sees now: the image the API resolved, as a string, on both
targets. A machine created from
alpinereportsalpine.The field is optional and nullable in the 1.16.1 spec, so this reads it
leniently: a serve older than 1.16.1 omits the key and still answers null,
and a machine with no image answers null too. Nothing else in the response
changes and no route is called that was not called before.
Verified on macOS against the 1.16.1 release archive: unit 174, the local
integration suites 10 passing with the cloud file skipped, the parity list
unchanged at 13 paths called and none unaccounted for, and a live machine
reporting its image through create, get and list. The new unit test was run
against the old line first and fails on it.