Understanding Curator's --master-only flag

Elastic Stack Elasticsearch
1

I'm running curator in every node in an N-node ELK cluster. Is there any
reason I wouldn't want to have the --master-only flag turned on?

If you delete an index from the master, it's still going to get deleted
from the other nodes right? I'm trying to understand why you would ever
not want to set this.

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/0e4c4006-609b-41cf-b3b5-499d5b7a497e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

2

You are correct in understanding that indices are deleted completely,
regardless of where its shards may reside.

This flag exists so that curator + the cron jobs can be installed—usually
for configuration management reasons—on ALL nodes in the cluster, but only
actually execute when run on the elected master node (as opposed to
merely an eligible master node).

If you try to run curator with this flag and the IP & port it is pointed at
is not the elected master, it will not complete the operations you
specify, but will exit with a message indicating it was not run on the
elected master.

--Aaron

On Monday, September 22, 2014 2:43:10 PM UTC-5, Matt Hughes wrote:

I'm running curator in every node in an N-node ELK cluster. Is there any
reason I wouldn't want to have the --master-only flag turned on?

If you delete an index from the master, it's still going to get deleted
from the other nodes right? I'm trying to understand why you would ever
not want to set this.

Create new page · elastic/curator Wiki · GitHub

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/20c2b134-be67-41b9-aca3-70cbe295defd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

3

In short, you are correct. You want that flag set on every node since
you've pushed curator to every node.

--Aaron

On Monday, September 22, 2014 4:00:41 PM UTC-5, Aaron Mildenstein wrote:

You are correct in understanding that indices are deleted completely,
regardless of where its shards may reside.

This flag exists so that curator + the cron jobs can be installed—usually
for configuration management reasons—on ALL nodes in the cluster, but only
actually execute when run on the elected master node (as opposed to
merely an eligible master node).

If you try to run curator with this flag and the IP & port it is pointed
at is not the elected master, it will not complete the operations you
specify, but will exit with a message indicating it was not run on the
elected master.

--Aaron

On Monday, September 22, 2014 2:43:10 PM UTC-5, Matt Hughes wrote:

I'm running curator in every node in an N-node ELK cluster. Is there any
reason I wouldn't want to have the --master-only flag turned on?

If you delete an index from the master, it's still going to get deleted
from the other nodes right? I'm trying to understand why you would ever
not want to set this.

Create new page · elastic/curator Wiki · GitHub

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/2bc11fc3-35be-4912-a43e-f1627b983f15%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.