docs: correct the floci split — layers of one deployment, not two paths - #62
Merged
Conversation
floci.md said m80 and floci answer different questions, m80 for the operator path and floci for the CloudFormation path, and that the operator harness needs only the first. The second half is right and the framing was wrong. Measured on 2026-08-02 rather than reasoned about. A KubeMicroVM deployment has three layers. Layer 1, the prerequisites: an S3 bucket holding the artifact and an IAM build role the service assumes to read it. Their setup-test-env.sh creates exactly this, and it runs against stock floci unmodified, producing a real bucket, a real role with trust and permissions policies, and an uploaded object. Layer 2, what the operator calls: four AWS SDK clients and no others. lambdamicrovms, lambdacore, sts and servicequotas. There is no S3Client, IamClient, Ec2Client or CloudFormationClient anywhere in KubeMicroVM — role ARNs and S3 URIs are strings it passes through. They meet cleanly, which is the part worth recording. Both emulators use account 000000000000, so a bucket and role ARN minted by floci go straight into CreateMicrovmImage on m80, which echoes the role back and builds to SUCCESSFUL. Verified by hand. Layer 3 is out of reach for both and always will be. Handed a build role and an S3 URI, the real service assumes that role and fetches that object itself. That happens inside AWS's implementation of a service being called, so there is no request to intercept and no endpoint to override. Saying so plainly is better than leaving a reader to assume more coverage exists. kubemicrovm.md also now says the operator harness does not need the bucket or the role to exist at all, since m80 takes both as opaque strings, so every case there passes against a bucket nobody created.
lex00
added a commit
that referenced
this pull request
Aug 2, 2026
The page is titled "division of labor with floci" and opened by describing a split, which left the dependency direction to be inferred. It is worth stating outright: the conformance suite never needed floci, the KubeMicroVM harness stopped needing it at #59, and m80 is one 8 MiB container with no companion. What remains runs the other way — m80's suite exports a subset:floci tag a second implementation can be held to. The three-layer deployment model added in #62 was correct and is mostly not m80's story. What justifies m80's scope is narrower: the operator depends on four AWS SDK clients and no others, and there is no S3, IAM, EC2 or CloudFormation client anywhere in KubeMicroVM. Role ARNs and S3 URIs are strings it hands to the MicroVMs API, so accepting them as opaque costs the operator nothing. That fact now lives on the scope page too, since it is what makes the refusals safe rather than merely convenient. The layer that provisions those prerequisites belongs to the adoption kit, which tracks it as INTENTIUS/kubemicrovm-ops#6, so this page points there instead of telling the story itself. Kept: the boundary neither emulator crosses. That one is m80's own honesty about what it can never do, and a reader who does not meet it will assume more coverage than exists.
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.
floci.mdsaid m80 and floci answer different questions — m80 the operator path, floci the CloudFormation path — and that the operator harness needs only the first. The second half is right; the framing was wrong.Measured rather than reasoned about.
Layer 1, prerequisites. An S3 bucket holding the artifact and an IAM build role the service assumes to read it. Their
setup-test-env.shcreates exactly this, and it runs against stock floci unmodified — real bucket, real role with trust and permissions policies, artifact uploaded.Layer 2, what the operator calls. Four AWS SDK clients and no others:
lambdamicrovmslambdacorests-serve-stsshimservicequotasQuotaDiscovery, off by defaultThere is no
S3Client,IamClient,Ec2ClientorCloudFormationClientanywhere in KubeMicroVM. Role ARNs and S3 URIs are strings it passes through.They meet cleanly, which is the part worth recording. Both emulators use account
000000000000, so a bucket and role ARN minted by floci go straight intoCreateMicrovmImageon m80, which echoes the role back and builds toSUCCESSFUL. Verified by hand.Layer 3 is out of reach for both, permanently. Handed a build role and an S3 URI, the real service assumes that role and fetches that object itself. That happens inside AWS's implementation of a service being called, so there is no request to intercept and no endpoint to override. Saying so plainly beats letting a reader assume more coverage exists.
kubemicrovm.mdalso now states that the operator harness does not need the bucket or role to exist, since m80 takes both as opaque strings — every case there passes against a bucket nobody created.