-
Notifications
You must be signed in to change notification settings - Fork 61
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
Proposal: standardize file locations & conventions for supporting files #91
Comments
A question and two comments:
|
Windows has .bat files and doesn't use permissions for what's an executable and what is not AFAIK. |
Overall, I like this proposal and having consistent directory structures. I have a few comments on specific suggestions: lib directory
I would think that if the plugin structures are being cleaned up, it might be nice to move the Jar files as well. OpenSearch's directory structure has a Scripts
I agree on keeping the Config/Data Directories
I do have some reservations on the This approach also helps when mounting volumes in Docker as well: That being said, a consistent directory structure can still afford for copying these config/data files. It would require a little more work to get the paths correct. Other Files Similar to the OpenSearch application, perhaps the standard can encourage a |
Any thoughts about how to avoid name collision if we were to do something like this? It's unlikely plugin authors could keep track of script names used in all other plugins. My first thought was subdirectories e.g. |
@jcgraybill , I do agree that the collisions can be a problem. And I also think that I'm not necessarily saying that all scripts should be symlinked into In regards to collisions, they are ultimately symlinks. So it is more of a convenience for plugin authors. I'd expect that once a script is symlinked that remains the symlink and they are not overridden. Thus, only the first installed plugin gets that name. |
Add load library paths to this, see opensearch-project/opensearch-build#879 (comment) |
I wanted to move this comment from here over to here:
I think native libraries are a bit challenging. All JNI libraries need to be in the "java.library.path" which we do not set by default. Also, "java.library.path" cannot be set at runtime. I think we could get creative with this, but I think it will require us to set a default "java.library.path" at the very least. For LD_LIBRARY_PATH, it is a little bit tricky. Setting "java.library.path" will make JNI libraries discoverable, but not their dependencies (even if they are in the same directory). This is where LD_LIBRARY_PATH needs to be set -- unless the JNI libraries can be compiled in such a way as to set RPATH to the directory they are in -- but this would make it more difficult to use 3rd party JNI libraries. |
Most of the OpenSearch plugins in the OpenSearch project include necessary or helpful things such as config files, tools and scripts, security certs, and postinstall/postremove scripts for some deployment environments. From plugin to plugin, these aren't in consistent locations: some are in subdirectories of the plugin itself, some are scattered around other directories in the distribution. Looking just at supporting scripts, they behave differently from each other. Some need $JAVA_HOME and $OPENSEARCH_HOME environment variables set, some autodetect them, some are Linux only, some are Linux/Windows.
This is worth standardizing. For somebody administering an OpenSearch cluster, they shouldn't need to figure out different adminstrator UX conventions feature by feature.
Looking at the current plugins, a few standards I would propose:
Interested in thoughts / feedback on this.
The text was updated successfully, but these errors were encountered: