-
Notifications
You must be signed in to change notification settings - Fork 25.6k
add version, policyname, and modifiedDate to ILM Explain API #33488
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
Conversation
|
Pinging @elastic/es-core-infra |
|
Hey @colings86, there is some more work to be done here, but I think there is enough to give a fair representation of the implementation direction. I'd appreciate the early feedback pending availability. It can wait until I finish off the TODOs too |
colings86
left a comment
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.
@talevy I left a comment but I think this is good so far.
| private static final ParseField PHASE_DEFINITION_FIELD = new ParseField("phase_definition"); | ||
| private static final ParseField VERSION_FIELD = new ParseField("version"); | ||
| private static final ParseField MODIFIED_DATE_FIELD = new ParseField("modified_date"); | ||
| private static final ParseField MODIFIED_DATE_STRING_FIELD = new ParseField("modified_date_string"); |
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 switch between the string and the millis representation fo the modified date using the human flag like the explain API already does? That way we can just have one modified_date field in the output? Also the parser will not need to worry about the string version in this case since the client it will never set the human flag
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.
yes. I forgot this was an option until I noticed that is happening elsewhere in ILM objects. I will update accordingly
dakrone
left a comment
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 doing this @talevy, I left some comments
|
|
||
| @Override | ||
| public String toString() { | ||
| return Strings.toString(this, true, true); |
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 you make this non-pretty, it's always weird when you log things and then end up being multi-line
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.
true, log lines are unfortunate, but comparing test assertions are. since one is in production, logging concerns win 👍
| builder.field(POLICY_NAME_FIELD.getPreferredName(), policyName); | ||
| builder.field(PHASE_DEFINITION_FIELD.getPreferredName(), phase); | ||
| builder.field(VERSION_FIELD.getPreferredName(), version); | ||
| if (builder.humanReadable()) { |
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.
For human readable-ness, an additional field should be added, we shouldn't replace the field with a human readable version.
You should be able to do
builder.timeField("modified_millis", "modified", modifiedDate);(replacing the field names with the fields we want to use)
and then you don't have to check the human readable flag yourself
...h-level/src/test/java/org/elasticsearch/client/indexlifecycle/IndexExplainResponseTests.java
Show resolved
Hide resolved
|
|
||
| @Override | ||
| public String toString() { | ||
| return Strings.toString(this, true, true); |
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.
Same here about multi-line toString methods
| builder.field(POLICY_NAME_FIELD.getPreferredName(), policyName); | ||
| builder.field(PHASE_DEFINITION_FIELD.getPreferredName(), phase); | ||
| builder.field(VERSION_FIELD.getPreferredName(), version); | ||
| if (builder.humanReadable()) { |
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 again I think we should use builder.timeField to handle this
| DeprecationHandler.THROW_UNSUPPORTED_OPERATION, phaseDef)) { | ||
| phaseExecutionInfo = PhaseExecutionInfo.parse(parser, currentPhase); | ||
| } catch (IOException e) { | ||
| logger.error("failed to parse [" + LifecycleSettings.LIFECYCLE_PHASE_DEFINITION + "] for index [" + index + "]", e); |
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 don't think we should swallow this error here, I think the request should error out also
x-pack/plugin/src/test/resources/rest-api-spec/test/ilm/40_explain_lifecycle.yml
Show resolved
Hide resolved
dakrone
left a comment
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, left a super minor comment
...lugin/core/src/main/java/org/elasticsearch/xpack/core/indexlifecycle/PhaseExecutionInfo.java
Show resolved
Hide resolved
...lugin/core/src/main/java/org/elasticsearch/xpack/core/indexlifecycle/PhaseExecutionInfo.java
Show resolved
Hide resolved
|
thanks for the review @dakrone! |
adds a section for phase execution to the Explain API. This contains - phase definition - policy name - policy version - modified date
Adds the currently executing policy-name, its version, and its modified date to the explain api
for every executing/managed index
TODO: