-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
User defined flux libraries #23179
Comments
@nathanielc what are your thoughts on this? To me, this would allow users to clean up a lot of their Flux queries and increase the usability of commonly used common functions. |
This is a great idea, we have captured some similar proposals here influxdata/flux#4296 This is on our roadmap |
Oh boy I'm sorry for the dup ... I searched but didn't use the word 'registry' or I would have found it. |
No worries, glad to see your independent proposal aligns well with what we were already thinking. Closing this and will continue tracking the issue in influxdata/flux#4296 |
Is this done now? This issue is all I can find. Pretty sick of copying my function code about. |
It seems that there isn't a solution for this... or does anyone has a workaround for this? |
Proposal:
Create a safe but easy method that allows influxdb administors and developers to add local libraries of flux functions.
Motivation
Increasingly I have small (usually) flux functions (as lambdas) that I create then reuse in multiple queries. Because I do not know of a way to import these functions from an external source I copy and pasting these functions in every query. This is not desirable for a number of reasons including code maintenance.
Desired behavior:
My preferred way to approach this would be to add a 'custom functions' page to the UI to allow users to write their own functions. Some basic syntax checking would be useful. These functions would be stored somewhere local - a good candidate might be the influxdb metadata database.
Functions could be created individually, or in packages. It might be easier to use packages because then they could be named and imported in regular queries explicitly. I think in the simplest implementation it could be almost like an #include - in fact, it's possible this whole thing could be implemented as 'include' rather than 'import' though importing a user-defined package seems more elegant to me.
Alternatives considered:
I considered the idea of having a file specified in config.toml that contains user defined packages, but thinking this through I'm not really in favor of that any longer. The reason is that when I'm creating/updating this user defined library I really don't want to be stopping and restarting the server.
Use case:
I think DRY is the real driver here. The reason to allow user-defined rather is to avoid polluting the flux ecosystem with a bunch of packages that aren't likely to be used by many query developers. In some cases, though, I can see the need for shared/community libraries, to leverage community creativity without necessarily having to commit to making changes to the standard flux libraries or forcing more functionality into 'experimental.'
Security:
I was initially a little worried that this might cause a security concern but the user defined functions wouldn't use any capabilities that a user couldn't do in a single query.
The text was updated successfully, but these errors were encountered: