CONTROL_PLANE_REF_NAME held the random suffix the Gateway operator gives
its auto-created mirror CR, looked up by hand. Replacing the Konnect org
recreated those CRs under new suffixes, so the ref named an object that
no longer existed and the domain's Kong entities sat Programmed=False.
Name the ${NAME}-cp mirror declared in k8s-platform's dataplane-template
instead — derived from NAME, so it stays valid across Gateway
recreations and Konnect org changes.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Post http-log to /customers instead of /logs. Fluent Bit's http input derives the
record tag from the request URI, so the path is what identifies this domain
in the collector and becomes the Loki label domain=customers.
The collector keeps writing every domain to the on-disk audit trail as
well, so this is reversible by restoring the previous path.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The second ai-mcp-proxy binding (added to fix the GET/SSE 502 loop)
created a second runtime plugin instance with the same tool config,
which ai-mcp-proxy's own duplicate-name detection caught: all three
tools (list-customers/get-customer/create-customer) fell back to
auto-generated names across both instances. Confirmed via dataplane
pod logs right after applying the previous fix.
Real fix: one KongRoute for all three MCP HTTP methods (GET/POST/
DELETE) instead of two, one ai-mcp-proxy binding instead of two.
ai-mcp-proxy already tolerates multi-method routes (same "skips
method selection" notice the existing POST+DELETE route already
produces) — extending to GET is the same class of thing, not new
risk, and there is now exactly one plugin instance so no duplicate
tool names.
The stream route (GET, mcp/routes.yaml) had no ai-mcp-proxy binding,
so GET requests fell through to the KongService's own upstream
target (REST_HOSTNAME, i.e. Kong's own external hostname) and
looped back into the Gateway, growing response headers each pass
until nginx rejected them (502, "upstream sent too big header").
Confirmed via customers dataplane pod logs while debugging a
LibreChat connection failure. catalog-mcp has the same structural
gap but happens to 405 instead of looping there — not touched here.
8 routes over Customer + orders/payments sub-resources, proxying to
classic-models-api. openid-connect with RFC 8693 token exchange to
classic-models-api audience, rate-limiting, proxy-cache, audit-log —
same plugin set and structure as catalog-api's REST surface.
Not deployed: dev/gitrepository.yaml points at a gitea repo that
doesn't exist yet (kong-customers-api.git, 404). No MCP layer yet
either, unlike catalog-api.
Stéphane Tailland