Skip to content

docs(anthropic-messages,maas-ipp): configurable vLLM endpoint + customer narrative - #14

Open
jordigilh wants to merge 1 commit into
praxis-proxy:mainfrom
jordigilh:docs/readme-fixes-aug12
Open

docs(anthropic-messages,maas-ipp): configurable vLLM endpoint + customer narrative#14
jordigilh wants to merge 1 commit into
praxis-proxy:mainfrom
jordigilh:docs/readme-fixes-aug12

Conversation

@jordigilh

Copy link
Copy Markdown
Contributor

What

Closes #10 and #11.

anthropic-messages (#10): passthrough.yaml/transform.yaml hardcoded a vLLM endpoint IP, forcing a manual edit of two files to run the demo against a different backend. They're now .tmpl files with "${VLLM_ENDPOINT}", expanded via envsubst (git-ignored once rendered) — the same pattern skillberry-agent-proxy already uses for environment-specific values in this repo.

maas-ipp (#11): the README was thorough on Forge/ops mechanics but had no "here's what you're about to see and why it matters" framing. Added a What this demo proves section and narrated the existing Call models curl steps, grounded in the actual MAAS_IPP_PROFILE switch (overlays/xks + IPP_IMAGE vs. overlays/xks-praxis + PRAXIS_EXTPROC_IMAGE) and Praxis's Pre-Auth/Post-Auth IPP contract — the point being that this demo proves Praxis can occupy MaaS's existing Envoy ExternalProcessor slot and preserve IPP's behavior, not that it's a new/separate datapath.

Verification

  • Rendered both .tmpl files with envsubst locally; diffed against the prior hardcoded YAML — byte-identical when VLLM_ENDPOINT matches the old default (10.0.0.99:8000).
  • Docs/config only, no code changes — matches both issues' stated scope.

DCO sign-off included.

anthropic-messages (demos#10): replace the hardcoded vLLM endpoint IP with
a configurable VLLM_ENDPOINT env var, consistent with how
skillberry-agent-proxy parameterizes environment-specific values --
passthrough.yaml/transform.yaml become .tmpl files expanded via envsubst
at run time (git-ignored once rendered), rather than files a demo runner
has to hand-edit.

maas-ipp (demos#11): add a customer-facing "What this demo proves" section
and narrate the existing "Call models" curl steps. Grounded in the actual
MAAS_IPP_PROFILE switch (overlays/xks vs overlays/xks-praxis, IPP_IMAGE vs
PRAXIS_EXTPROC_IMAGE) and Praxis's documented Pre-Auth/Post-Auth IPP
contract: this demo proves Praxis can sit in MaaS's existing Envoy
ExternalProcessor slot and preserve IPP's pre/post-auth behavior, not that
it introduces a new datapath -- that's the actual customer/roadmap-relevant
claim, not just "the curl works."

Documentation/config only, no code changes -- matches both issues' stated
scope.

Signed-off-by: Jordi Gil <jgil@redhat.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

docs(anthropic-messages): replace hardcoded vLLM IP with a configurable env var

1 participant