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

Increment tribe node version on updates #13566

Merged
merged 1 commit into from Sep 21, 2015

Conversation

Projects
None yet
3 participants
@imotov
Member

imotov commented Sep 15, 2015

Currently the tribe node version always stays 0, which can cause issues for the services that rely on cluster state version. For example, ClusterStateObserver doesn't revalidate the cluster state after change, which leads to cluster health check with wait flags to take much longer then actually needed.

@bleskes

This comment has been minimized.

Show comment
Hide comment
@bleskes

bleskes Sep 15, 2015

Member

Good catch. LGTM. We need the 3.0 & 2.1 labels too imho.

IMHO this should be automatic and you shouldn't have to remember to increment it (just like UUIDs are). I'll give it some thought..

Member

bleskes commented Sep 15, 2015

Good catch. LGTM. We need the 3.0 & 2.1 labels too imho.

IMHO this should be automatic and you shouldn't have to remember to increment it (just like UUIDs are). I'll give it some thought..

@imotov

This comment has been minimized.

Show comment
Hide comment
@imotov

imotov Sep 16, 2015

Member

The version is incremented by ClusterService during update. The reason it is needed here explicitly is somewhat strange nature of a tribe node with its non-master updates that don't increment version.

Member

imotov commented Sep 16, 2015

The version is incremented by ClusterService during update. The reason it is needed here explicitly is somewhat strange nature of a tribe node with its non-master updates that don't increment version.

Increment tribe node version on updates
Currently the tribe node version always stays 0, which can cause issues for the services that rely on cluster state version. For example, ClusterStateObserver doesn't revalidate the cluster state after change, which leads to cluster health check with wait flags to take much longer then actually needed.

@imotov imotov merged commit e09e43a into elastic:master Sep 21, 2015

1 check passed

CLA Commit author is a member of Elasticsearch
Details

@clintongormley clintongormley added v2.0.0-rc1 and removed v2.0.0 labels Oct 7, 2015

@clintongormley clintongormley removed the v2.1.0 label Nov 22, 2015

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