Stop returning cluster state size by default #40016
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Computing the compressed size of the cluster state on every invocation of cluster:monitor/state action is expensive, and the value of this field is dubious anyway. Therefore we want to remove computing this field. As a first step, we stop computing and return this field by default. To avoid breaking users, we will give them a system property to use to tide them over until the next major release when we will actually remove this field. This comes with a deprecation warning too, and the backport to the appropriate minor will also include a note in the migration guide. There will be a follow-up to remove this field in the next major version.
jasontedor
added
>breaking
v7.0.0
:Distributed Indexing/Distributed
Collaborator
|
Pinging @elastic/es-distributed |
DaveCTurner
approved these changes
Mar 13, 2019
Contributor
DaveCTurner
left a comment
DaveCTurner
left a comment
There was a problem hiding this comment.
LGTM, thanks @jasontedor
jasontedor
commented
Mar 14, 2019
jasontedor
commented
Mar 14, 2019
jasontedor
commented
Mar 14, 2019
jasontedor
commented
Mar 14, 2019
rest-api-spec/src/main/resources/rest-api-spec/test/cluster.state/10_basic.yml
Outdated
Show resolved
Hide resolved
…ate/10_basic.yml Fix BWC version
Contributor
|
Tests failed because of #40030 (now muted in master) |
jasontedor
added a commit
that referenced
this pull request
Mar 14, 2019
Computing the compressed size of the cluster state on every invocation of cluster:monitor/state action is expensive, and the value of this field is dubious anyway. Therefore we want to remove computing this field. As a first step, we stop computing and return this field by default. To avoid breaking users, we will give them a system property to use to tide them over until the next major release when we will actually remove this field. This comes with a deprecation warning too, and the backport to the appropriate minor will also include a note in the migration guide. There will be a follow-up to remove this field in the next major version.
jasontedor
added a commit
that referenced
this pull request
Mar 14, 2019
Computing the compressed size of the cluster state on every invocation of cluster:monitor/state action is expensive, and the value of this field is dubious anyway. Therefore we want to remove computing this field. As a first step, we stop computing and return this field by default. To avoid breaking users, we will give them a system property to use to tide them over until the next major release when we will actually remove this field. This comes with a deprecation warning too, and the backport to the appropriate minor will also include a note in the migration guide. There will be a follow-up to remove this field in the next major version.
jasontedor
added a commit
that referenced
this pull request
Mar 14, 2019
Computing the compressed size of the cluster state on every invocation of cluster:monitor/state action is expensive, and the value of this field is dubious anyway. Therefore we want to remove computing this field. As a first step, we stop computing and return this field by default. To avoid breaking users, we will give them a system property to use to tide them over until the next major release when we will actually remove this field. This comes with a deprecation warning too, and the backport to the appropriate minor will also include a note in the migration guide. There will be a follow-up to remove this field in the next major version.
jasontedor
added a commit
that referenced
this pull request
Mar 14, 2019
This work has been backported all the way now, so this commit adjusts the BWC version. Relates #40016
jasontedor
added a commit
that referenced
this pull request
Mar 14, 2019
This work has been backported all the way now, so this commit adjusts the BWC version. Relates #40016
jasontedor
added a commit
that referenced
this pull request
Mar 14, 2019
This work has been backported all the way now, so this commit adjusts the BWC version. Relates #40016
DaveCTurner
added a commit
to DaveCTurner/elasticsearch
that referenced
this pull request
Mar 15, 2019
The `GET /_cluster/state` API returns an internal representation of the cluster state that does change from version to version. It's useful for debugging, but it is not intended for regular use by clients. This change adjusts the documentation of `GET /_cluster/state` to clarify that this API yields an internal representation that should not be expected to remain stable between versions. Relates elastic#40061, elastic#40016
This was referenced Mar 15, 2019
DaveCTurner
added a commit
that referenced
this pull request
Mar 18, 2019
The `GET /_cluster/state` API returns an internal representation of the cluster state that does change from version to version. It's useful for debugging, but it is not intended for regular use by clients. This change adjusts the documentation of `GET /_cluster/state` to clarify that this API yields an internal representation that should not be expected to remain stable between versions. Relates #40061, #40016
DaveCTurner
added a commit
that referenced
this pull request
Mar 18, 2019
The `GET /_cluster/state` API returns an internal representation of the cluster state that does change from version to version. It's useful for debugging, but it is not intended for regular use by clients. This change adjusts the documentation of `GET /_cluster/state` to clarify that this API yields an internal representation that should not be expected to remain stable between versions. Relates #40061, #40016
DaveCTurner
added a commit
that referenced
this pull request
Mar 18, 2019
The `GET /_cluster/state` API returns an internal representation of the cluster state that does change from version to version. It's useful for debugging, but it is not intended for regular use by clients. This change adjusts the documentation of `GET /_cluster/state` to clarify that this API yields an internal representation that should not be expected to remain stable between versions. Relates #40061, #40016
DaveCTurner
added a commit
that referenced
this pull request
Mar 18, 2019
The `GET /_cluster/state` API returns an internal representation of the cluster state that does change from version to version. It's useful for debugging, but it is not intended for regular use by clients. This change adjusts the documentation of `GET /_cluster/state` to clarify that this API yields an internal representation that should not be expected to remain stable between versions. Relates #40061, #40016
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Computing the compressed size of the cluster state on every invocation of cluster:monitor/state action is expensive, and the value of this field is dubious anyway. Therefore we want to remove computing this field. As a first step, we stop computing and return this field by default. To avoid breaking users, we will give them a system property to use to tide them over until the next major release when we will actually remove this field. This comes with a deprecation warning too, and the backport to the appropriate minor will also include a note in the migration guide. There will be a follow-up to remove this field in the next major version.
Relates #39806
Relates #39827
Relates #39951