-
Notifications
You must be signed in to change notification settings - Fork 1.3k
feat: introduce /admin API for stack administration and operations #4401
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
working through testing issues, some will fail on this PR while others should pass. This is because the tests use an unpublished client to test new API. This client will be published right after the PR merges so then CI will go green on main. |
|
tests work! but they fail due to legitimate resourcing issues with the admin group in the client: https://github.com/llamastack/llama-stack/actions/runs/20288111386/job/58267005772 will dig into this and fix tomorrow. PR should then be set to merge. |
|
This pull request has merge conflicts that must be resolved before it can be merged. @cdoern please rebase it. https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork |
✱ Stainless preview buildsThis PR will update the
|
954dd24 to
843b1c6
Compare
|
new one note @ashwinb , the tests pass and run but no recordings are generated when using |
|
CI is red? |
@ashwinb so on these types of PRs, the replay integration tests will be red. but the action I linked to also runs the integration test using the newly generated client from the Stainless SDK job. The reason CI is red is because Let me know if that makes sense |
raghotham
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approving despite failures. Got clarification from @cdoern in the office hours
|
once this merges, |
|
rebased to get the CI changes. |
- Add new /admin API (v1alpha) for administrative operations including provider management, health checks, version info, and route listing
- Implement using FastAPI routers following batches pattern with proper request/response models
- Endpoints: /admin/providers, /admin/providers/{id}, /admin/inspect/routes, /admin/health, /admin/version
- Create admin module structure: models.py, api.py, fastapi_routes.py, __init__.py
- Add AdminImpl in llama_stack/core combining provider and inspect functionality
- Deprecate standalone /providers and /inspect APIs (remain functional for backward compatibility)
- Consolidate duplicate types: ProviderInfo, HealthInfo, RouteInfo, etc. now defined once in admin.models
- Test new API using Stainless SDK in integration tests
Signed-off-by: Charlie Doern <cdoern@redhat.com>
|
ok, lets see if https://github.com/llamastack/llama-stack/actions/runs/20350287754/job/58472853387?pr=4401 passes edit: all passed! |
| admin: | ||
| methods: | ||
| list_providers: get /v1alpha/admin/providers | ||
| inspect_provider: get /v1alpha/admin/providers/{provider_id} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh this feels odd
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was debating between this or
/v1alpha/admin/providers
/v1alpha/admin/{provider_id}
same for the other "nested" routes, I am unsure how much nesting we want/don't want. Either way it is alpha so we can change it if we want!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We will probably have other resources like attributes for abac in /admin. So, suggest leaving /providers in there. And like @cdoern mentioned, its still alpha, so we can change it later if this doesnt feel right.
…lamastack#4401) - Add new /admin API (v1alpha) for administrative operations including provider management, health checks, version info, and route listing - Implement using FastAPI routers following batches pattern with proper request/response models - Endpoints: /admin/providers, /admin/providers/{id}, /admin/inspect/routes, /admin/health, /admin/version - Create admin module structure: models.py, api.py, fastapi_routes.py, init.py - Add AdminImpl in llama_stack/core combining provider and inspect functionality - Deprecate standalone /providers and /inspect APIs (remain functional for backward compatibility) - Consolidate duplicate types: ProviderInfo, HealthInfo, RouteInfo, etc. now defined once in admin.models new admin integration suite, uses generated stainless SDK, and records new tests on this PR. Signed-off-by: Charlie Doern <cdoern@redhat.com>
…lamastack#4401) # What does this PR do? - Add new /admin API (v1alpha) for administrative operations including provider management, health checks, version info, and route listing - Implement using FastAPI routers following batches pattern with proper request/response models - Endpoints: /admin/providers, /admin/providers/{id}, /admin/inspect/routes, /admin/health, /admin/version - Create admin module structure: models.py, api.py, fastapi_routes.py, init.py - Add AdminImpl in llama_stack/core combining provider and inspect functionality - Deprecate standalone /providers and /inspect APIs (remain functional for backward compatibility) - Consolidate duplicate types: ProviderInfo, HealthInfo, RouteInfo, etc. now defined once in admin.models ## Test Plan new admin integration suite, uses generated stainless SDK, and records new tests on this PR. Signed-off-by: Charlie Doern <cdoern@redhat.com>
What does this PR do?
Test Plan
new admin integration suite, uses generated stainless SDK, and records new tests on this PR.