-
Notifications
You must be signed in to change notification settings - Fork 24.8k
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
Unable to start AWS discovery with 2.0.0-SNAPSHOT #12643
Comments
We need tests that test this stuff... that needs to block any bugfix here. I know if someone can fix it, they will feel pressure to push fix without tests. But we cannot develop software this way anymore! |
So I tried to run
And it went well. My config is:
Same when running from command line with So I get only this when deploying the plugin in elasticsearch and trying to load AWS module. |
ok, I think one thing we can do is cutover the thirdparty tests to run in the integration test phase so they run realistically? they are definitely integration tests. then they can be run in jenkins and we have more coverage for the discovery plugins: currently their integration tests only check that they were installed. |
So the problem is coming from the changes in ClassLoading. The Discovery Module is started within a Node using the Node settings (and the Node classloader aka elasticsearch core classloader). Discovery then tries to call something like settings.getClassLoader() is actually elasticsearch core Classloader, not the plugin one. So we need somehow to tell the discovery module that he should use the plugin Classloader if any. I'm not sure yet how to do that. I pushed some changes for now in my branch https://github.com/dadoonet/elasticsearch/tree/plugins/discovery but it does not fix the issue. It only falls back to the default discovery instead of failling elasticsearch to start. |
To reproduce the issue: Build aws or azure plugin:
Build core:
Build a distribution:
Change discovery.type: ec2 Then start elasticsearch. If you want to iterate other the code, just in core run |
the default classloader. It had all kinds of leniency in how the classname was found, and simply cannot work with plugins having isolated classloaders. This change removes that method. Some of the uses of it were for custom extension points, like custom repository or discovery types. A lot were just there to plugin mock implementations for tests. For the settings that were legitimate, all now support plugins adding the given setting via onModule. For those that were specific to tests for mocks, they now use Classes.loadClass (a helper around Class.forName). This is a temporary measure until (in a future PR) tests can change the implementation via package private statics. I also removed a number of unnecessary intermediate modules, added a "jvm-example" plugin that can be filled in in the future as a smoke test for breaking plugins, and gave some documentation to "spawn" modules interface. closes elastic#12643 closes elastic#12656
I started 2 AWS instances using latest 2.0.0-SNAPSHOT I built locally.
When starting with defaults, everything is fine.
When changing
elasticsearch.yml
to:I get this error while launching:
The cloud plugin contains needed libs I think:
And the cloud jar file contains the class we are looking for:
org/elasticsearch/discovery/ec2/Ec2DiscoveryModule.class
The text was updated successfully, but these errors were encountered: