Skip to content

[ENH] Auto-set tenant in python CloudClient, add AdminCloudClient #5026

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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

jairad26
Copy link
Contributor

@jairad26 jairad26 commented Jul 3, 2025

Description of changes

This PR updates the python CloudClient to auto-set tenant based on the API key, and deprecates unnecessary fields such as tenant, cloud_port, and enable_ssl. It also adds the AdminCloudClient, which introduces a new interface class, since cloud admin APIs are not 1:1 with the existing admin APIs. CloudAdminClient does not allow users to pass in tenants to functions, and will instead fetch the tenant using the provided api key at init time, and reuse that.

to use the cloud client now

client = chromadb.CloudClient(
    api_key="ck-xxxxxxxxx"
)

Test plan

How are these changes tested?

Manually tested both clients, and all corresponding APIs for both CloudClient (collection apis, add/delete records), and AdminClient (get_tenant & list/get_database, confirm create_tenant and create_database are disabled)

  • Tests pass locally with pytest for python, yarn test for js, cargo test for rust

Documentation Changes

Are all docstrings for user-facing APIs updated if required? Do we need to make documentation changes in the docs section?

Copy link
Contributor Author

jairad26 commented Jul 3, 2025

This stack of pull requests is managed by Graphite. Learn more about stacking.

Copy link

github-actions bot commented Jul 3, 2025

Reviewer Checklist

Please leverage this checklist to ensure your code review is thorough before approving

Testing, Bugs, Errors, Logs, Documentation

  • Can you think of any use case in which the code does not behave as intended? Have they been tested?
  • Can you think of any inputs or external events that could break the code? Is user input validated and safe? Have they been tested?
  • If appropriate, are there adequate property based tests?
  • If appropriate, are there adequate unit tests?
  • Should any logging, debugging, tracing information be added or removed?
  • Are error messages user-friendly?
  • Have all documentation changes needed been made?
  • Have all non-obvious changes been commented?

System Compatibility

  • Are there any potential impacts on other parts of the system or backward compatibility?
  • Does this change intersect with any items on our roadmap, and if so, is there a plan for fitting them together?

Quality

  • Is this code of a unexpectedly high quality (Readability, Modularity, Intuitiveness)

@jairad26 jairad26 force-pushed the jai/cloud-client branch 4 times, most recently from 14a2d65 to e609337 Compare July 4, 2025 17:26
@jairad26 jairad26 marked this pull request as ready for review July 4, 2025 17:47
Copy link
Contributor

propel-code-bot bot commented Jul 4, 2025

Auto-set Tenant in CloudClient and Introduce AdminCloudClient

This PR refactors the Python CloudClient to automatically derive the tenant from the API key, deprecating the explicit 'tenant', 'cloud_port', and 'enable_ssl' parameters, which are now ignored with deprecation warnings for backward compatibility. An AdminCloudClient is also added, with a specialized AdminCloudAPI interface that does not allow user-supplied tenants and instead uses the tenant resolved at initialization from the API key. Associated tests have been rewritten to use mocking, and environment/configuration handling was updated. The PR also introduces documentation and type updates, removes obsolete parameters, and unifies settings initialization across clients.

Key Changes

• CloudClient no longer requires explicit 'tenant', 'cloud_port', and 'enable_ssl' arguments; tenant is auto-populated from the API key, and deprecation warnings are introduced for those fields.
• Added AdminCloudClient which uses an AdminCloudAPI interface, inferring the tenant at construction and disallowing explicit tenant passing for operations.
• Adjustments to init files for proper re-exports and AdminCloudClient exposure, and internal settings streamlined: always SSL with port 443 for CloudClient/AdminCloudClient.
• Comprehensive update in tests to use unittest.mock and test the implicit tenant/database logic, removing the need for subprocess/multiprocess or real server setup.
• Auxiliary changes in authentication utility for more robust tenant/database inference, tightening singleton database selection logic.

Affected Areas

• chromadb/init.py
• chromadb/api/client.py
• chromadb/api/init.py
• chromadb/test/client/test_cloud_client.py
• chromadb/auth/utils/init.py

This summary was automatically generated by @propel-code-bot

@jairad26 jairad26 force-pushed the jai/cloud-client branch from e609337 to e9ff7e0 Compare July 4, 2025 19:49
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.

1 participant