-
Notifications
You must be signed in to change notification settings - Fork 32
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
Add metadata transformations with metadata tuples #1148
Add metadata transformations with metadata tuples #1148
Conversation
fbecea3
to
488c664
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #1148 +/- ##
============================================
+ Coverage 80.77% 80.94% +0.16%
- Complexity 2952 2995 +43
============================================
Files 400 407 +7
Lines 15111 15229 +118
Branches 1021 1023 +2
============================================
+ Hits 12206 12327 +121
+ Misses 2287 2273 -14
- Partials 618 629 +11
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
RFS/src/main/java/org/opensearch/migrations/bulkload/worker/IndexRunner.java
Outdated
Show resolved
Hide resolved
MetadataMigration/src/main/java/org/opensearch/migrations/commands/Evaluate.java
Outdated
Show resolved
Hide resolved
|
||
import lombok.extern.slf4j.Slf4j; | ||
|
||
/** Shared functionality between migration and evaluation commands */ | ||
@Slf4j | ||
public abstract class MigratorEvaluatorBase { | ||
public static final String NOOP_TRANSFORMATION_CONFIG = "[" + |
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.
Lets remove this, if there is no transformation config why create and use the factory?
...va/org/opensearch/migrations/bulkload/transformers/TransformerToIJsonTransformerAdapter.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.
Thanks for the work here! Looking forward to seeing some tests to help understand the user experience a bit better. Overall, feels like a good first step as we continue to iterate and evolve our vision for transformations.
var transformedTemplates = Stream.concat(Stream.concat( | ||
legacyTemplates.stream(), | ||
indexTemplates.stream()), | ||
componentTemplates.stream() | ||
) | ||
.map(this::transformMigrationItem).collect(Collectors.toList()); |
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.
Why combine all the different migration item types into an undifferentiated stream, transform, then split them up again? Wouldn't it be easier and more efficient to just apply the transform to each class individually?
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.
Here, we are supporting the case where someone migrates from legacy templates to index templates
log.atInfo().setMessage("BeforeJsonGlobal: {}").addArgument(() -> printMap(inputJson)).log(); | ||
var afterJson = transformer.transformJson(inputJson); | ||
log.atInfo().setMessage("AfterJsonGlobal: {}").addArgument(() -> printMap(afterJson)).log(); |
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 interesting to have a pre-processor transform for the global metadata but not the index settings. Is this an opinionated stance or just a matter of current necessity? Also - how does this fit into the bigger picture we previously discussed of having user-supplied bulk pre/post processing transforms then line-item transforms for each individual MigrationItem between those two steps?
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've cleaned this up in the latest version, the unit of transformation for index settings is the entire object, whereas for global metadata it's the sub-object (individual template).
.../main/java/org/opensearch/migrations/bulkload/version_es_7_10/IndexMetadataData_ES_7_10.java
Show resolved
Hide resolved
RFS/src/main/java/org/opensearch/migrations/bulkload/worker/IndexRunner.java
Outdated
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.
Thanks for the tests, looks like maybe there is some kind of refactoring we can do in the future to cleanup the setup / verification that is very similar between the tests, but this gives me a lot of confidence that we will know when we break something - much appreciated.
Seems like there is a one off system index that is causing the new test cases to fail and some style cop changes, but the bones of this good to me once CI is passing.
Signed-off-by: Andre Kurait <[email protected]>
Signed-off-by: Andre Kurait <[email protected]>
Signed-off-by: Andre Kurait <[email protected]>
Signed-off-by: Andre Kurait <[email protected]>
fa7896e
to
22b509f
Compare
Signed-off-by: Andre Kurait <[email protected]>
22b509f
to
18e83bb
Compare
Description
Add metadata transformations with metadata tuples.
Adds SKIPPED migration failure type
Issues Resolved
#1115
https://opensearch.atlassian.net/browse/MIGRATIONS-2157
Is this a backport? If so, please add backport PR # and/or commits #
Testing
Unit tests added, aws testing for log format and location
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.