Skip to content
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

[ILM] Add date setting to calculate index age #46561

Merged
merged 10 commits into from
Sep 12, 2019

Conversation

andreidan
Copy link
Contributor

Add the index.lifecycle.origination_date to allow users to configure a
custom date that'll be used to calculate the index age for the phase
transmissions (as opposed to the default index creation date).

This could be useful for users to create an index with an "older"
origination date when indexing old data.

Relates to #42449.

  • Have you signed the contributor license agreement?
  • Have you followed the contributor guidelines?
  • If submitting code, have you built your formula locally prior to submission with gradle check?
  • If submitting code, is your pull request against master? Unless there is a good reason otherwise, we prefer pull requests against master and will backport as needed.
  • If submitting code, have you checked that your submission is for an OS and architecture that we support?
  • If you are submitting this code for a class then read our policy for that.

Add the `index.lifecycle.origination_date` to allow users to configure a
custom date that'll be used to calculate the index age for the phase
transmissions (as opposed to the default index creation date).

This could be useful for users to create an index with an "older"
origination date when indexing old data.

Relates to elastic#42449.
@andreidan andreidan added 7x :Data Management/ILM+SLM Index and Snapshot lifecycle management >enhancement labels Sep 10, 2019
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-core-features

@andreidan andreidan removed the 7x label Sep 10, 2019
@@ -259,6 +269,7 @@ public int hashCode() {
private Long phaseTime;
private Long actionTime;
private Long stepTime;
private Long indexOriginationDate;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As the index.creation_date and index.lifecycle.origination_date settings have default values, would it be worth working with primitives here?

Copy link
Member

@dakrone dakrone left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I left some comments on this, I think we should approach it more towards the "read time" rather than overwriting the creation date when initializing the policy.

@dakrone
Copy link
Member

dakrone commented Sep 10, 2019

@andreidan can you also add version labels to this PR? Since this is an enhancement it should go to 8.0.0 and 7.5.0 (latest master and 7.x branch versions)

The initial approach we took was to override the lifecycle creation date
if the `index.lifecycle.origination_date` setting was set. This had the
disadvantage of the user not being able to update the `origination_date`
anymore once set.

This commit changes the way we makes use of the
`index.lifecycle.origination_date` setting by checking its value when
we calculate the index age (ie. at "read time") and, in case it's not
set, default to the index creation date.
@andreidan
Copy link
Contributor Author

retest this please

@andreidan andreidan requested a review from dakrone September 11, 2019 12:58
Copy link
Member

@dakrone dakrone left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This approach looks much better, thanks @andreidan, I left some more comments that should be addressed, but nothing major

@@ -208,6 +208,7 @@ public void validate(Integer numRoutingShards, Map<Setting<Integer>, Integer> se
public static final String SETTING_VERSION_UPGRADED = "index.version.upgraded";
public static final String SETTING_VERSION_UPGRADED_STRING = "index.version.upgraded_string";
public static final String SETTING_CREATION_DATE = "index.creation_date";

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It'd be good to revert the changes to this file since we don't need it any more (we tend to try not to touch files that don't have code changes even if it would make it cleaner)

return new LifecycleExecutionState(phase, action, step, failedStep, stepInfo, phaseDefinition, indexCreationDate,
phaseTime, actionTime, stepTime);
return new LifecycleExecutionState(phase, action, step, failedStep, stepInfo, phaseDefinition,
indexCreationDate, phaseTime, actionTime, stepTime);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here we can probably undo this change (less changes of any conflicts in the future since this change likely won't go back to 7.4 and below)

@@ -17,6 +17,7 @@
public static final String LIFECYCLE_POLL_INTERVAL = "indices.lifecycle.poll_interval";
public static final String LIFECYCLE_NAME = "index.lifecycle.name";
public static final String LIFECYCLE_INDEXING_COMPLETE = "index.lifecycle.indexing_complete";
public static final String SETTING_LIFECYCLE_ORIGINATION_DATE = "index.lifecycle.origination_date";
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor nit, we can drop the SETTING_ prefix from the var since this is just the string rather than a Setting option

case the `min_age` will be the time elapsed since that specified date. If the
index is rolled over, then `min_age` is the time elapsed from the time the
index is rolled over. The intention here is to execute following phases and
actions relative to when data was written last to a rolled over index.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this documentation looks good, but can you also add some in ilm-settings.asciidoc for the index.lifecycle.origination_date setting

createIndexRequest("test").settings(
Settings.builder()
.put(settings)
.put(LifecycleSettings.SETTING_LIFECYCLE_ORIGINATION_DATE, 1000L)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you add another check underneath this that setting this setting back to null goes back to using the original lifecycle creation date?

@@ -29,6 +30,8 @@
Setting.Property.Dynamic, Setting.Property.IndexScope);
public static final Setting<Boolean> LIFECYCLE_INDEXING_COMPLETE_SETTING = Setting.boolSetting(LIFECYCLE_INDEXING_COMPLETE, false,
Setting.Property.Dynamic, Setting.Property.IndexScope);
public static final Setting<Long> LIFECYCLE_ORIGINATION_DATE_SETTING =
Setting.longSetting(SETTING_LIFECYCLE_ORIGINATION_DATE, -1, -1, Setting.Property.IndexScope, Setting.Property.NodeScope);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this setting NodeScope? I think it should be IndexScope and Dynamic (so that it's updateable after index creation).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch :)

@andreidan
Copy link
Contributor Author

retest this please

Copy link
Member

@dakrone dakrone left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks for iterating on this @andreidan

public long settingsVersion() {
return settingsVersion;
}

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could revert the changes to this file (just so it doesn't end up in the change list), but it is so minor it's up to you.

@andreidan
Copy link
Contributor Author

@elasticmachine test this please

@andreidan
Copy link
Contributor Author

@elasticmachine update branch

@andreidan andreidan merged commit d5bd2bb into elastic:master Sep 12, 2019
andreidan added a commit to andreidan/elasticsearch that referenced this pull request Sep 13, 2019
* [ILM] Add date setting to calculate index age

Add the `index.lifecycle.origination_date` to allow users to configure a
custom date that'll be used to calculate the index age for the phase
transmissions (as opposed to the default index creation date).

This could be useful for users to create an index with an "older"
origination date when indexing old data.

Relates to elastic#42449.

* [ILM] Don't override creation date on policy init

The initial approach we took was to override the lifecycle creation date
if the `index.lifecycle.origination_date` setting was set. This had the
disadvantage of the user not being able to update the `origination_date`
anymore once set.

This commit changes the way we makes use of the
`index.lifecycle.origination_date` setting by checking its value when
we calculate the index age (ie. at "read time") and, in case it's not
set, default to the index creation date.

* Make origination date setting index scope dynamic

* Document orignation date setting in ilm settings

(cherry picked from commit d5bd2bb)
Signed-off-by: Andrei Dan <[email protected]>
andreidan added a commit that referenced this pull request Sep 16, 2019
* [ILM] Add date setting to calculate index age

Add the `index.lifecycle.origination_date` to allow users to configure a
custom date that'll be used to calculate the index age for the phase
transmissions (as opposed to the default index creation date).

This could be useful for users to create an index with an "older"
origination date when indexing old data.

Relates to #42449.

* [ILM] Don't override creation date on policy init

The initial approach we took was to override the lifecycle creation date
if the `index.lifecycle.origination_date` setting was set. This had the
disadvantage of the user not being able to update the `origination_date`
anymore once set.

This commit changes the way we makes use of the
`index.lifecycle.origination_date` setting by checking its value when
we calculate the index age (ie. at "read time") and, in case it's not
set, default to the index creation date.

* Make origination date setting index scope dynamic

* Document orignation date setting in ilm settings

(cherry picked from commit d5bd2bb)
Signed-off-by: Andrei Dan <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants