Document registry server_api_url for the Cloud UI - #1069
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
There was a problem hiding this comment.
Pull request overview
Updates ToolHive Enterprise documentation to reflect the enterprise config split of the registry directive into two URLs, clarifying that the Enterprise Cloud UI uses server_api_url (Registry Server API root) rather than the ToolHive-client-shaped api_url.
Changes:
- Updated Cloud UI “Registry API URL resolution” to use
server_api_urlinstead ofapi_url, and added an explanatory note about URL shape and 404s. - Added a “Registry URL for the Cloud UI” variation to the Enterprise Manager registry policy docs, documenting
api_urlvsserver_api_urlside-by-side. - Added an upgrade-ordering warning about Enterprise Manager rejecting unknown config fields.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| docs/platform/enterprise-manager/policies/registry.mdx | Adds a Cloud UI-specific variation documenting server_api_url alongside api_url, plus an upgrade warning. |
| docs/platform/enterprise-cloud-ui/configure.mdx | Updates Cloud UI registry URL resolution to use server_api_url and adds a note explaining the two URL shapes and the 404 failure mode. |
danbarr
left a comment
danbarr
left a comment
There was a problem hiding this comment.
There's some over-explanation and unnecessary negation that can be trimmed here, suggestions inline. Also, this should not be merged until this change is actually released.
|
Applied all four suggestions in 614f8cd (note removed, paragraph reworded per your suggestion, fallback-only sentence kept, upgrade warning dropped). Agreed on timing — this stays unmerged until the release carrying |
|
FYI: This needs to be included after the next enterprise release ⌛ |
The enterprise config's registry directive now carries two URLs (stacklok-enterprise-platform#2823): api_url stays the ToolHive- client-shaped registry endpoint, and the new server_api_url is the Registry Server API root the Cloud UI resolves against. The Cloud UI's "Registry API URL resolution" section previously named api_url as the config-server source, which is now the one value it ignores. Also documents the upgrade-ordering rule: the Enterprise Manager rejects unknown config fields, so deploy the platform version that introduces the field before setting it.
Acknowledge both api_url shapes (registry root vs per-registry path on a Stacklok Registry Server) instead of implying one is typical, and remove the em dash per the style guide.
Drop the Cloud UI note restating the resolution list, take the suggested rewording of the two-URL paragraph, keep only the fallback sentence, and remove the upgrade warning (operational norm, belongs in release notes).
614f8cd to
17c2b22
Compare
Description
stacklok-enterprise-platform#2823 split the enterprise config's registry directive into two URLs:
api_urlstays the ToolHive-client-shaped registry endpoint (scoped to one registry, e.g.https://registry.acme.com/registry/toolhive), and the newserver_api_urlis the Registry Server API root the Cloud UI resolves against.Two pages needed updating:
enterprise-cloud-ui/configure.mdx— the "Registry API URL resolution" section namedapi_urlas the config-server source for the Cloud UI, which after the split is the one value it deliberately ignores. Updated toserver_api_url, with a note explaining the two URL shapes and why pointing the Cloud UI at the client-shaped URL 404s.enterprise-manager/policies/registry.mdx— new "Registry URL for the Cloud UI" variation documenting both fields side by side, plus a warning on the upgrade-ordering rule: the Enterprise Manager rejects unknown configuration fields and refuses to start, so the platform version introducingserver_api_urlmust be deployed before the field is added to config.npm run buildpasses (anchors/links verified by the build).Type of change
Related issues/PRs
Submitter checklist
Content and formatting