Communication mechanism JS (Part 1) #761
Conversation
Signed-off-by: Varun Jain <varunudr@amazon.com>
| // TODO: After AnomalyDetectorJob.java is uncommented, fetch jobIndex from AnomalyDetectorJob | ||
| @Override | ||
| public JobDetails getJobDetails() { | ||
| return new JobDetails(AnomalyDetectorPlugin.AD_JOB_TYPE, ".opendistro-anomaly-detector-jobs"); |
There was a problem hiding this comment.
We should use Job index constant here ANOMALY_DETECTOR_JOB_INDEX.
Also, getJobDetails is equivalent to which JobScheduler extension point here?
For ADplugin, we have getJobIndex() and getJobType()
There was a problem hiding this comment.
I have not pulled ANOMALY_DETECTOR_JOB_INDEX from AnomalyDetectorJob because the class is commented. I have mentioned the same in TODO
There was a problem hiding this comment.
@owaiskazi19 JobDetails is equivalent to both getJobIndex() and getJobType(). Both these strings are utilized by Job Scheduler to configure it's behavior for onIndexModule() and to also configure the indexToJobProviders which the JobSweeper uses to schedule jobs. I also agree that we should use the ANOMALY_DETECTOR_JOB_INDEX constant, @vibrantvarun it should be fine to uncomment this
There was a problem hiding this comment.
I want to understand more on why are we coupling up getJobIndex() and getJobType() together in jobDetails?Shouldn't it follow the old design of keeping them separate or otherwise we have to change these extension points in all the plugins/extensions using JS?
There was a problem hiding this comment.
getJobIndex and getJobType are currently used by Job Scheduler to retrieve implementations of the JobSchedulerExtension interface here. Simply put, these two extension points just provide strings to Job Scheduler.
We're coupling the Job Index and Job Type strings together in one request, rather than separate requests since this is the only initial information we need from extensions in order to configure both the indicesToListen set and indexToJobProviders hashmap. How these are further used is documented here. Separating these into two requests would be unnecessary.
This wouldn't have any affect on how plugins are using JS, since the plugin architecture for JS remains untouched within PluginsService's loadExtensionsForPlugin workflow. As for extensions, the only difference at this point is how we are providing these strings to Job Scheduler. How Job Scheduler uses these strings will remain unchanged.
There was a problem hiding this comment.
Hi @joshpalis @owaiskazi19 the job index cannot be pulled from AnomalyDetectorJob.java as of now because it still has circular dependency from JS on some other methods written in the file. If I uncomment only the required code like the Job Index initialization then I am facing an error of jacoco test coverage report. Therefore, for now I am hardcoding the value of job index.
There was a problem hiding this comment.
We can fix the jacoco test coverage by uncommenting the tests too
There was a problem hiding this comment.
Yes I did uncomment the code, but there are some dependencies which are imported from JobScheduler like Schedule.java etc. These dependencies cannot be resolved until they are imported from JS native plugin.
There was a problem hiding this comment.
Makes sense. Let's create a constant in this file then
|
DCO check is failing. Commit using |
Description
Request Response model to fetch Job details like job index and job type from extensions.
Issues Resolved
opensearch-project/opensearch-sdk-java#274
Companion PR
OpenSearch opensearch-project/OpenSearch#5586
opensearch-sdk-java opensearch-project/opensearch-sdk-java#289
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.