-
Notifications
You must be signed in to change notification settings - Fork 1.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
Add to and from XContent to ClusterBlock and ClusterBlocks #13694
Add to and from XContent to ClusterBlock and ClusterBlocks #13694
Conversation
❌ Gradle check result for 75ce997: FAILURE Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change? |
75ce997
to
215a135
Compare
❌ Gradle check result for 215a135: FAILURE Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change? |
Created a new issue for unrealted failing test |
215a135
to
141b86b
Compare
❌ Gradle check result for 141b86b: null Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change? |
Failing test already identified as flaky |
❌ Gradle check result for 141b86b: null Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change? |
141b86b
to
ee86138
Compare
❌ Gradle check result for ee86138: FAILURE Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change? |
ee86138
to
ba27fd1
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #13694 +/- ##
============================================
+ Coverage 71.42% 71.56% +0.14%
- Complexity 59978 61136 +1158
============================================
Files 4985 5059 +74
Lines 282275 287628 +5353
Branches 40946 41671 +725
============================================
+ Hits 201603 205829 +4226
- Misses 63999 64761 +762
- Partials 16673 17038 +365 ☔ View full report in Codecov by Sentry. |
for (ClusterBlockLevel level : levels) { | ||
builder.value(level.name().toLowerCase(Locale.ROOT)); | ||
} | ||
builder.endArray(); | ||
if (context == Metadata.XContentContext.GATEWAY) { |
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.
Can this cause BWC failures for non-remote cluster?
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.
We are only passing GATEWAY as a context when custom metadata should be stored as part of the persistent cluster state. Don't see any reason this could cause any BWC issue.
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.
Is there a possibility of mismatch of nodes with old and new version of this code? (say OpenSearch 2.14 upgrading to 2.15). In that case, this additional fields (introduced in 2.15) can't be read by older nodes running in 2.14.
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 XContent we are creating is not being sent to the nodes of older version. We will just be uploading this to remote repo. In case of upgrade, we will start publication of cluster state to nodes, when all the nodes have moved to 2.15. So, this would not cause any problem imo
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.
Would it not be consumed by the data nodes from remote?
return new ClusterBlock(id, uuid, description, retryable, disableStatePersistence, allowReleaseResources, status, levels); | ||
} | ||
|
||
private static String skipBlockID(XContentParser parser) throws IOException { |
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.
Can we add explanation of why this is needed? Probably an example will help here
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 have written the fromXContent is a way that if it can parse the ClusterBlock as a XContentFragment as well as a complete Object. This specific method is added to enable the parsing ClusterBlock as a complete XContentObject like given below.
{
"block-1" : {
"uuid": ....
}
}
Although, we might never need to parse such object. But the UT I have written in ClusterBlockTests.java
, we are creating a complete XContentObject from cluster block and trying to parse it back to ClusterBlock object, that is the reason this was required.
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.
How do we differentiate between XContentObject and XConentFragment? Can we separate XContentObject parsing to a separate function and then use the above method to parse the XConentFragment inside that?
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.
XContentObject has a paired start end object. While for fragment that is not true. Sure, we can separate the logic to parse the fragment to a innerParser
and use that in fromXContent
method which can accept both Object and a Fragment.
server/src/main/java/org/opensearch/cluster/block/ClusterBlock.java
Outdated
Show resolved
Hide resolved
server/src/main/java/org/opensearch/cluster/block/ClusterBlocks.java
Outdated
Show resolved
Hide resolved
Signed-off-by: Shivansh Arora <[email protected]>
ba27fd1
to
dd7babd
Compare
❌ Gradle check result for dd7babd: FAILURE Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change? |
Signed-off-by: Shivansh Arora <[email protected]>
dd7babd
to
d69ae20
Compare
❌ Gradle check result for d69ae20: FAILURE Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change? |
for (ClusterBlockLevel level : levels) { | ||
builder.value(level.name().toLowerCase(Locale.ROOT)); | ||
} | ||
builder.endArray(); | ||
if (context == Metadata.XContentContext.GATEWAY) { |
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.
Is there a possibility of mismatch of nodes with old and new version of this code? (say OpenSearch 2.14 upgrading to 2.15). In that case, this additional fields (introduced in 2.15) can't be read by older nodes running in 2.14.
if (token == XContentParser.Token.FIELD_NAME) { | ||
currentFieldName = parser.currentName(); | ||
} else if (token.isValue()) { | ||
switch (Objects.requireNonNull(currentFieldName)) { |
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.
currentFiledName will always be non null after first field. For this logic to work, currentFieldName should be reset, once the corresponding value is parsed.
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, it will always be non Null. I think I will get rid of this nonNull check rather than resetting the field every time we parse something.
return new ClusterBlock(id, uuid, description, retryable, disableStatePersistence, allowReleaseResources, status, levels); | ||
} | ||
|
||
private static String skipBlockID(XContentParser parser) throws IOException { |
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.
How do we differentiate between XContentObject and XConentFragment? Can we separate XContentObject parsing to a separate function and then use the above method to parse the XConentFragment inside that?
Description
We need to upload the ClusterBlocks object to remote to enable the cluster state publication flow from remote. To do that we need to parse ClusterBlocks object to and from XContent.
Related Issues
Resolves #13692
Check List
- [x] Commit changes are listed out in CHANGELOG.md file (See: Changelog)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.