You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 2bbe577
Browse filesBrowse the repository at this point in the historyBrowse files
feat(gateways): one deployment shape, and a pre-deploy check that it holds
Every gateway is now deployed the same way: drop its config files, set its env,
set its headers, run its commands, and the harness states the core limits last.
Nothing else, and the engine understands none of it.
COMMANDS, for the one gateway that has no config file. It keeps its
configuration in a database and is configured through its own admin API after
boot, so there is nothing to drop next to the binary and no honest way to deploy
it except to make the calls its documentation describes. `commands` is a file of
lines, discovered by name exactly like `env` and `headers.json`, run in order
once the gateway answers as ready and before anything is measured. The engine
does not read what they write and does not know what they do, the same way it
does not know what a header does. definition.json is unchanged.
THE HARNESS STATES THE CORE COUNT, not the gateway. A cpuset restricts which
cores a process may use; it does not change what a runtime believes is
available, and a runtime that reads the machine's CPU count sizes its pools for
sixteen cores while confined to four. That was left to each gateway to remember
and it drifted exactly as that always does: both manifests that set it lost the
setting in the port and nothing noticed, because the gateway still booted. The
harness now appends the limits after the gateway's own env, so a gateway cannot
opt out of the size it is being measured at.
kong and gomodel get their env back. Both launched with empty env blocks for the
same reason, which is why one never bound its port and the other started with no
upstream at all.
apisix's route template contained a shell function call that the retired manifest
used to expand. Nothing expands it now, so the literal text went into the YAML,
the routes would not parse, and the gateway answered every probe 404: it
published as an entrant that serves nothing. Expanded to data, and validate now
refuses a config template containing a command substitution, because a config is
data and nothing runs to produce one.
THE NECESSITY RULE IS CHECKED AGAIN. The published methodology promises a
setting appears only if it boots the process, points an upstream at the mock,
exposes an ingress path, or binds the port and cores. The lint enforcing that
read its claims from GW_CONFIG_WHY inside gateway.sh, which is dead code nothing
loads, so the claims described a deployment that no longer existed and the parts
that grew afterwards were covered by nothing. All 294 claims move into a `why`
file per gateway, and lib/gateway_deploy_lint.sh checks env, headers and
commands against them. Proven by planting an unjustified setting and watching it
fail.
"{}: contains a shell command substitution, which nothing will expand: {:?}. A config template is data; write the literal value or use a {{PLACEHOLDER}}",
0 commit comments