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

Use ILM for Watcher history deletion #37443

Merged
merged 10 commits into from
Jan 23, 2019

Conversation

dakrone
Copy link
Member

@dakrone dakrone commented Jan 14, 2019

This commit adds an index lifecycle policy for the .watch-history-* indices.
This policy is automatically used for all new watch history indices.

This does not yet remove the automatic cleanup that the monitoring plugin does
for the .watch-history indices, and it does not touch the
xpack.watcher.history.cleaner_service.enabled setting.

Relates to #32041

There is one TODO about how much we should enforce parity with the on-disk policy, thoughts are appreciated.

This commit adds an index lifecycle policy for the `.watch-history-*` indices.
This policy is automatically used for all new watch history indices.

This does not yet remove the automatic cleanup that the monitoring plugin does
for the .watch-history indices, and it does not touch the
`xpack.watcher.history.cleaner_service.enabled` setting.

Relates to elastic#32041
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-core-features

@dakrone
Copy link
Member Author

dakrone commented Jan 15, 2019

In our discussion we decided to only put the policy if one didn't exist, not to replace a changed or previously existing policy with the on disk version.

I'll make the charge for this accordingly.

return LifecyclePolicyUtils.loadPolicy(POLICY_WATCH_HISTORY.policyName, POLICY_WATCH_HISTORY.fileName, xContentRegistry);
}

private void addIndexLifecyclePolicyIfMissing(ClusterState state) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Are there any concerns about multiple nodes entering this path and putting the policy multiple times ?

Copy link
Member Author

Choose a reason for hiding this comment

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

Since this only happens when the local node is master, it should only get called once with the atomic compareAndSet below. Also any subsequent calls would see that the policy already existed and not replace it

Copy link
Contributor

Choose a reason for hiding this comment

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

ahh.. thanks, I missed this will only run on the master.

Copy link
Contributor

Choose a reason for hiding this comment

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

minor nit: it is not only the master node, but is also put when this node is newer than the master node. The reason for this is, that with regards to the watcher history, a node that is not the master node might be updated first in a cluster, and that one could write the watch history in a format which requires a new watch history template.

I am not sure if this applies to ILM as well, as this is an administrative task compared to the fact that the watch history is written by non master nodes.

@@ -46,17 +53,23 @@
TEMPLATE_CONFIG_TRIGGERED_WATCHES, TEMPLATE_CONFIG_WATCH_HISTORY, TEMPLATE_CONFIG_WATCHES
};

public static final PolicyConfig POLICY_WATCH_HISTORY = new PolicyConfig("watch-history-policy", "/watch-history-policy.json");
Copy link
Contributor

Choose a reason for hiding this comment

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

I remember the discussion to not use a . in the name since this is something that we don't mind users changing. However, I wonder if in the UI there should be some kind of differentiation policies we add vs. policies they add. If so we may want the . after all.

@bmcconaghy - Do you see any reason that the UI for ILM (now or in the future) should differentiate between policies added by the system vs. policies added by a human ?

Choose a reason for hiding this comment

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

I remember the discussion to not use a . in the name since this is something that we don't mind users changing. However, I wonder if in the UI there should be some kind of differentiation policies we add vs. policies they add. If so we may want the . after all.

@bmcconaghy - Do you see any reason that the UI for ILM (now or in the future) should differentiate between policies added by the system vs. policies added by a human ?

When we're making amendments to config through the API, we expect system-created objects to being with a . character, and hence we avoid those.

I think it would make sense to adhere to that pattern; it's a bit surprising that you've deviated from it.

Moreover, if a user were to delete this policy because they thought it had been created by another user rather than the system, the system would consequently behave differently to how it's specified to behave in the docs.

Copy link
Contributor

@hub-cap hub-cap left a comment

Choose a reason for hiding this comment

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

Some general questions but looks pretty durn good to me

Copy link
Contributor

@jakelandis jakelandis left a comment

Choose a reason for hiding this comment

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

LGTM and thanks for setting the ground work for future system indices.

@dakrone
Copy link
Member Author

dakrone commented Jan 17, 2019

@elasticmachine run gradle build tests 2

1 similar comment
@dakrone
Copy link
Member Author

dakrone commented Jan 17, 2019

@elasticmachine run gradle build tests 2

@dakrone
Copy link
Member Author

dakrone commented Jan 22, 2019

@elasticmachine run elasticsearch-ci/2

@dakrone
Copy link
Member Author

dakrone commented Jan 23, 2019

@elasticmachine run elasticsearch-ci/docs-check

@dakrone dakrone merged commit 427bc7f into elastic:master Jan 23, 2019
jasontedor added a commit to jasontedor/elasticsearch that referenced this pull request Jan 23, 2019
* master:
  Liberalize StreamOutput#writeStringList (elastic#37768)
  Add PersistentTasksClusterService::unassignPersistentTask method (elastic#37576)
  Tests: disable testRandomGeoCollectionQuery on tiny polygons (elastic#37579)
  Use ILM for Watcher history deletion (elastic#37443)
  Make sure PutMappingRequest accepts content types other than JSON. (elastic#37720)
  Retry ILM steps that fail due to SnapshotInProgressException (elastic#37624)
  Use disassociate in preference to deassociate (elastic#37704)
  Delete Redundant RoutingServiceTests (elastic#37750)
  Always return metadata version if metadata is requested (elastic#37674)
jasontedor added a commit to jasontedor/elasticsearch that referenced this pull request Jan 24, 2019
* elastic/master: (85 commits)
  Use explicit version for build-tools in example plugin integ tests (elastic#37792)
  Change `rational` to `saturation` in script_score (elastic#37766)
  Deprecate types in get field mapping API (elastic#37667)
  Add ability to listen to group of affix settings (elastic#37679)
  Ensure changes requests return the latest mapping version (elastic#37633)
  Make Minio Setup more Reliable (elastic#37747)
  Liberalize StreamOutput#writeStringList (elastic#37768)
  Add PersistentTasksClusterService::unassignPersistentTask method (elastic#37576)
  Tests: disable testRandomGeoCollectionQuery on tiny polygons (elastic#37579)
  Use ILM for Watcher history deletion (elastic#37443)
  Make sure PutMappingRequest accepts content types other than JSON. (elastic#37720)
  Retry ILM steps that fail due to SnapshotInProgressException (elastic#37624)
  Use disassociate in preference to deassociate (elastic#37704)
  Delete Redundant RoutingServiceTests (elastic#37750)
  Always return metadata version if metadata is requested (elastic#37674)
  [TEST] Mute MlMappingsUpgradeIT testMappingsUpgrade
  Streamline skip_unavailable handling (elastic#37672)
  Only bootstrap and elect node in current voting configuration (elastic#37712)
  Ensure either success or failure path for SearchOperationListener is called (elastic#37467)
  Target only specific index in update settings test
  ...
@dakrone dakrone deleted the ilm-use-ilm-for-watcher-history branch February 4, 2019 14:42
@gwbrown gwbrown mentioned this pull request Feb 5, 2019
11 tasks
@willemveerman
Copy link

Hey just an idea, should this policy's name start with a . character so it follows the pattern for other system objects?

@cachedout
Copy link
Contributor

This does not yet remove the automatic cleanup that the monitoring plugin does
for the .watch-history indices, and it does not touch the
xpack.watcher.history.cleaner_service.enabled setting.

Is this work planned for a future release and if so, is there a GH issue that I can follow?

@matschaffer
Copy link
Contributor

@willemveerman I had the same thought so opened #51589

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants