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.

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

Implement Python API for Influx 3.0 to be used for processing engine #25618

Open
jacksonrnewhouse opened this issue Dec 4, 2024 · 2 comments

Comments

@jacksonrnewhouse
Copy link
Contributor

In order for python code written by users in python to interact with the database, they need a python API that allows various operations. As an initial list, they should be able to

  • Access database schema information, including listing out all of the tables with their schemas and metadata.
  • Write data back into a possibly new database in the table. To start with this will be writing line protocol data into a table, similar to the /api/v3/write_lp API call.
  • Run queries against existing data in the database.

This should behave somewhat similar to an active client making API calls to a remote server, even though it will in fact be making direct calls against Rust types passed through python using PyO3.

@jacksonrnewhouse jacksonrnewhouse self-assigned this Dec 4, 2024
@jdstrand
Copy link
Contributor

jdstrand commented Dec 6, 2024

In order for python code written by users in python to interact with the database, they need a python API that allows various operations

What is the authz here? It seems clear (to me anyway!) that script invocations should have database permissions associated with them. One way to do this is to associate a token with a given invocation of the script. Please see my thoughts in #25537 (comment)

@jdstrand
Copy link
Contributor

jdstrand commented Dec 6, 2024

What is the authz here? It seems clear (to me anyway!) that script invocations should have database permissions associated with them. One way to do this is to associate a token with a given invocation of the script. Please see my thoughts in #25537 (comment)

After internal discussion with @pauldix - AIUI (please correct me!) OSS will have an 'all or nothing token' for all aspects of interacting with the influxdb API (meaning database read/write as well as script upload; if a script was successfully uploaded then it will have access to the database). My suggestion of "associate a token with a given invocation of the script" is consistent with this: since there are only all access tokens and an all access token allowed upload of the script and the script has access to read and write to the database.

I might suggest when implementing considering how you might disallow scripts from accessing the scripts API or accessing influxdb files directly. I wouldn't say this is strictly required for a prototype or even MVP, but it would help keep the system robust in the face of scripting errors.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants