m80 served exactly two service models until 2026-08-02, when -serve-sts added a third protocol for one action. The reasoning is in the package doc and it holds. What does not exist is a rule, and one is now needed, because a second request has already arrived.
servicequotas:GetServiceQuota is called by the operator's QuotaDiscovery for six rate quotas. It is off by default (aws.quota.discovery.enabled=false) and every lookup falls back to a configured value on exception, so nothing breaks today. But it is a path nobody can exercise against m80, and m80 already models the quota behaviour those numbers describe.
Answering it case by case is how an emulator becomes a general AWS emulator by accident, one reasonable request at a time. floci already exists and is good at being that.
The rule, proposed
m80 serves a non-MicroVMs call only when all of these hold:
- A consumer cannot proceed without it. The STS gate blocks operator readiness entirely; without an answer nothing works. Quota discovery being off by default does not meet this.
- The answer is constant and knowable.
GetCallerIdentity returns m80's own account. Anything requiring state, evaluation or a decision is out.
- One action, refused loudly at the edges. Every other action on that protocol answers 501 saying m80 is not an emulator of that service.
- It is recorded in
docs/scope.md as both a thing m80 does and a thing m80 refuses beyond that action.
Anything failing these belongs behind AWS_ENDPOINT_URL pointed at floci, which is what the KubeMicroVM harness does for every other service.
Decide on servicequotas under that rule
By the rule above it does not qualify: off by default, falls back cleanly, and the six values are configuration rather than a constant fact about the account. So the answer is no unless someone reports being blocked.
The counter-argument worth hearing: it is six integers, m80 already enforces the ceiling they describe, and refusing means the one path that reads them cannot be tested locally at all.
Either way, record the decision rather than leaving it to whoever hits it next.
Also settle m80's relationship to floci
m80 depends on floci for nothing. It never did for the conformance suite, and since #59 it does not for the operator harness either. What remains is one-directional: m80's suite exports a subset:floci tag that a second implementation can be held to, and a floci build passes it at 26 checks.
docs/floci.md should say that plainly. The deployment-layer story it currently carries belongs to the adoption kit, which now tracks it as INTENTIUS/kubemicrovm-ops#6.
m80 served exactly two service models until 2026-08-02, when
-serve-stsadded a third protocol for one action. The reasoning is in the package doc and it holds. What does not exist is a rule, and one is now needed, because a second request has already arrived.servicequotas:GetServiceQuotais called by the operator'sQuotaDiscoveryfor six rate quotas. It is off by default (aws.quota.discovery.enabled=false) and every lookup falls back to a configured value on exception, so nothing breaks today. But it is a path nobody can exercise against m80, and m80 already models the quota behaviour those numbers describe.Answering it case by case is how an emulator becomes a general AWS emulator by accident, one reasonable request at a time. floci already exists and is good at being that.
The rule, proposed
m80 serves a non-MicroVMs call only when all of these hold:
GetCallerIdentityreturns m80's own account. Anything requiring state, evaluation or a decision is out.docs/scope.mdas both a thing m80 does and a thing m80 refuses beyond that action.Anything failing these belongs behind
AWS_ENDPOINT_URLpointed at floci, which is what the KubeMicroVM harness does for every other service.Decide on servicequotas under that rule
By the rule above it does not qualify: off by default, falls back cleanly, and the six values are configuration rather than a constant fact about the account. So the answer is no unless someone reports being blocked.
The counter-argument worth hearing: it is six integers, m80 already enforces the ceiling they describe, and refusing means the one path that reads them cannot be tested locally at all.
Either way, record the decision rather than leaving it to whoever hits it next.
Also settle m80's relationship to floci
m80 depends on floci for nothing. It never did for the conformance suite, and since #59 it does not for the operator harness either. What remains is one-directional: m80's suite exports a
subset:flocitag that a second implementation can be held to, and a floci build passes it at 26 checks.docs/floci.mdshould say that plainly. The deployment-layer story it currently carries belongs to the adoption kit, which now tracks it as INTENTIUS/kubemicrovm-ops#6.