Skip to content
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.

Sign up for GitHub

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

Jump to bottom

[ENH] - Add new endpoint(s) to avoid needing internal knowledge of conda-store's database #1042

Open
peytondmurray opened this issue Jan 9, 2025 · 2 comments · May be fixed by #1046
Open

[ENH] - Add new endpoint(s) to avoid needing internal knowledge of conda-store's database #1042

peytondmurray opened this issue Jan 9, 2025 · 2 comments · May be fixed by #1046
Labels
area: api 🌐 needs: investigation 🔎 Someone in the team needs to look into this issue before scoping

Comments

@peytondmurray
Copy link
Contributor

Feature description

See nebari-dev/nebari#2815 for more information about what internal functions are needed by nebari.

We should create whatever REST endpoints are necessary for nebari to avoid having to call internal conda-store functions.

Value and/or benefit

Access to the internal python API should not be necessary; fixing this will reduce the chance of breaking changes for users.

Anything else?

No response
@peytondmurray peytondmurray added area: api 🌐 needs: investigation 🔎 Someone in the team needs to look into this issue before scoping labels Jan 9, 2025
@marcelovilla
Copy link

@peytondmurray thanks for opening this issue!

Just to clarify something, are you considering adding the functionality Nebari relies on as REST endpoints, or expose them in the conda-store Python API? If it's the former, I think it's already covered, at least judging from what's available in the REST API docs. Here's a small table outlining the Python functions we're using and (what I think) are the equivalent REST endpoints:

Python function REST API endpoint
get_namespace GET /api/v1/namespace/{namespace}/
ensure_namespace POST /api/v1/namespace/{namespace}/
create_namespace_role POST /api/v1/namespace/{namespace}/role
delete_namespace_role DELETE /api/v1/namespace/{namespace}/role

I was assuming the preferred way of interacting with conda-store from the configuration file was the Python API (maybe because historically we have been relying on that) but we would certainly be able to change to the REST API if it makes more sense.

@peytondmurray
Copy link
Contributor Author

If it's the former, I think it's already covered

I think you're right. So our goal here would be to expose a Python API that doesn't require access to the db or db schema.

I was assuming the preferred way of interacting with conda-store from the configuration file was the Python API (maybe because historically we have been relying on that) but we would certainly be able to change to the REST API if it makes more sense.

IMO we should support either approach, so I think there is something to be addressed here, and it's the Python API.

@soapy1 soapy1 linked a pull request Jan 14, 2025 that will close this issue
Open
3 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
area: api 🌐 needs: investigation 🔎 Someone in the team needs to look into this issue before scoping
Projects
conda-store 🐍
Status: New 🚦
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Move auth related schema to inside the auth module soapy1/conda-store
2 participants
@peytondmurray @marcelovilla