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

Avoid deprecation warnings due to monitoring index templates. #37442

Closed
jtibshirani opened this issue Jan 14, 2019 · 4 comments
Closed

Avoid deprecation warnings due to monitoring index templates. #37442

jtibshirani opened this issue Jan 14, 2019 · 4 comments

Comments

@jtibshirani
Copy link
Contributor

jtibshirani commented Jan 14, 2019

When putting and getting templates, monitoring currently uses the old typed APIs. In particular, the type name is included in the mapping definition, and when communicating over REST, the parameter include_type_name=true is specified.

When we soon deprecate the typed put + get templates calls on master, this will result in us issuing deprecation warnings when the monitoring http exporter is used. This won't be a great experience for users, as they'll receive deprecation warnings that are out of their control to fix. Note that if the http exporter needs to be able to connect to a 6.7 cluster, then include_type_name should be explicitly provided and set to false, since include_type_name defaults to true in 6.7 (whereas on master it defaults to false).

@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-core-features

@kesslerm
Copy link

The new parameter include_type_name breaks remote monitoring if the remote cluster is still on an older version of Elasticsearch.

@jtibshirani
Copy link
Contributor Author

@kesslerm I don't think this is a supported configuration. From https://www.elastic.co/guide/en/elastic-stack-overview/current/how-monitoring-works.html:

In general, the monitoring cluster and the clusters being monitored should be running the same version of the stack. A monitoring cluster cannot monitor production clusters running newer versions of the stack.

When deciding how to tackle warnings in monitoring, we relied on this restriction (that the remote cluster must be upgraded first).

@jtibshirani
Copy link
Contributor Author

Closing this issue, as it was addressed in the linked PRs.

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

No branches or pull requests

4 participants