-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
[Feature/extensions] Added unit tests and modified extension read logic for ExtensionsOrch… #3449
[Feature/extensions] Added unit tests and modified extension read logic for ExtensionsOrch… #3449
Conversation
…estrator Signed-off-by: Ryan Bogan <rbogan@amazon.com>
server/src/test/java/org/opensearch/extensions/ExtensionsOrchestratorTests.java
Outdated
Show resolved
Hide resolved
server/src/test/java/org/opensearch/extensions/ExtensionsOrchestratorTests.java
Show resolved
Hide resolved
server/src/test/java/org/opensearch/extensions/ExtensionsOrchestratorTests.java
Outdated
Show resolved
Hide resolved
server/src/test/java/org/opensearch/extensions/ExtensionsOrchestratorTests.java
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did a single pass.
Mostly the changes look good. Lets take care of the comments and I'll do another pass today.
Thanks @ryanbogan
TransportService transportService; | ||
final DiscoveryNode extensionNode; | ||
DiscoveryNode defaultExtensionNode; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we still need this ?
We do not need a default Extension node, we should always walk through all extensions when invoking extension points.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just set the defaultExtensionNode to the first extension read because we need it for IndicesModuleRequest
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The first extension should not be special :).
With the code we had, it was hacky to enable our manual testing.
We dont need this any more.
For every extension point we should walk through every extension.
server/src/test/java/org/opensearch/extensions/ExtensionsOrchestratorTests.java
Outdated
Show resolved
Hide resolved
extensionsSet.add( | ||
new DiscoveryExtension( | ||
extension.getName(), | ||
"id", | ||
extension.getName(), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are we simply using the name as the persistent ID? Or is this a placeholder?
Should it not be extension.getId()
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's just a placeholder for now, but I'll try to switch it over since that makes more sense
@@ -3,11 +3,11 @@ extensions: | |||
ephemeralId: uniqueid1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This isn't part of this PR, but isn't the ephemeralId
auto-assigned, and should this be the (unique) persistent id?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I'll change it
Signed-off-by: Ryan Bogan <rbogan@amazon.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! 🚢
Signed-off-by: Ryan Bogan <rbogan@amazon.com>
…fied unit tests accordingly Signed-off-by: Ryan Bogan <rbogan@amazon.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @ryanbogan for these changes.
The changes look good to me.
Some minor comments, few of them could be taken care in follow up PRs.
server/src/main/java/org/opensearch/extensions/ExtensionsOrchestrator.java
Outdated
Show resolved
Hide resolved
new TransportAddress(TransportAddress.META_ADDRESS, Integer.parseInt(extension.getPort())), | ||
new HashMap<String, String>(), | ||
Version.fromString(extension.getVersion()), | ||
pluginInfo |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I honestly dont remember why we are storing plugin Info.
I think we should be able to get rid of walking through pluginDirs
server/src/main/java/org/opensearch/extensions/ExtensionsOrchestrator.java
Outdated
Show resolved
Hide resolved
server/src/main/java/org/opensearch/extensions/ExtensionsOrchestrator.java
Outdated
Show resolved
Hide resolved
Signed-off-by: Ryan Bogan <rbogan@amazon.com>
new DiscoveryExtension( | ||
extension.getName(), | ||
extension.getUniqueId(), | ||
// placeholder for ephemeral id, will change with POC discovery |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we will always have a unique ephemeral id, why are we using a set?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It worked better with the findPluginDirectories method that we were using to find extensions. In another PR that I will hopefully raise later today, I will be removing all of the logic related to pluginDirs so I could change it to a list if that's what you recommend
server/src/main/java/org/opensearch/extensions/ExtensionsOrchestrator.java
Outdated
Show resolved
Hide resolved
server/src/main/java/org/opensearch/extensions/ExtensionsOrchestrator.java
Show resolved
Hide resolved
server/src/main/java/org/opensearch/extensions/ExtensionsOrchestrator.java
Outdated
Show resolved
Hide resolved
Signed-off-by: Ryan Bogan <rbogan@amazon.com>
Signed-off-by: Ryan Bogan <rbogan@amazon.com>
.put(IndexMetadata.SETTING_VERSION_CREATED, Version.CURRENT) | ||
.put(Environment.PATH_HOME_SETTING.getKey(), createTempDir().toString()) | ||
.build(); | ||
ExtensionsOrchestrator orchestrator = new ExtensionsOrchestrator(settings, extensionDir); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: orchestrator
-> extenionsOrchestrator
Signed-off-by: Ryan Bogan <rbogan@amazon.com>
…estrator
Signed-off-by: Ryan Bogan rbogan@amazon.com
Description
Adds unit tests and reads extensions from file automatically in ExtensionsOrchestrator.
Issues Resolved
3408
Check List
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.