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

The term for "maintenance" nodes #7148

Closed
leventov opened this issue Feb 26, 2019 · 9 comments
Closed

The term for "maintenance" nodes #7148

leventov opened this issue Feb 26, 2019 · 9 comments
Milestone

Comments

@leventov
Copy link
Member

The "maintenance" mode of historical nodes introduced in #6349 confused me recently so raise this issue with 0.14.0 milestone while it's not too late to change the name relatively easily.

I like @glasser's suggestion "draining", I think it reflects the essence of the mode more clearly than "maintenance".

@leventov
Copy link
Member Author

@gianm
Copy link
Contributor

gianm commented Feb 26, 2019

It sounds like the feature in #6349 is a way of telling the coordinator to move all data off a particular historical. "Decommission" seems to be the most popular word to use to describe that kind of operation in other systems I checked just now. It also strikes me as pretty intuitive. So I'd suggest that.

@leventov
Copy link
Member Author

@gianm thanks for the analysis and providing the data.

Now I'm in favor of "decommission".

@jon-wei
Copy link
Contributor

jon-wei commented Feb 26, 2019

"Decommission" sounds good to me.

@clintropolis
Copy link
Member

clintropolis commented Feb 26, 2019

I don't have strong opinions here, "draining" and "decommission" both do sound a bit more intuitive than "maintenance". "draining" seems more popular with orchestration things like mesos, kubernetes, docker swarm, etc, but I think either are appropriate here, so count this as a vote for changing to one or the other.

@clintropolis
Copy link
Member

Actually.. 👍 for "decommission" because it seems more appropriate terminology for this application level function, and we are closer to kafka/cassandra/hadoop than mesos/kubernetes/etc so it seems more consistent.

@glasser
Copy link
Contributor

glasser commented Feb 27, 2019

I'd be interested in making/using a layer on top of this feature where you send an API request to the historical itself and it adds itself to the coordinator's decommission list. (See @clintropolis at #6349 (comment).)

I think "decommission" goes well with this potential feature, especially since one could include an "exit when empty" flag on the API. A decommissioning that ends with exiting feels fitting.

@gianm
Copy link
Contributor

gianm commented Feb 27, 2019

It sounds like people generally like "decommission". Since this is a 0.14.0 blocker we'd want to make this change soon (so we can keep progressing towards a release candidate). Is anyone interested in implementing this change?

@clintropolis
Copy link
Member

I can pick this up this afternoon if no one else claims it.

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

5 participants