# Wait for yellow status

**URL:** <https://discuss.elastic.co/t/wait-for-yellow-status/17679>\
**Category:** Elasticsearch\
**Created:** [May 22, 2014, 4:20pm UTC](https://discuss.elastic.co/t/wait-for-yellow-status/17679 "2014-05-22T16:20:48Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![Ivan](https://avatars.discourse-cdn.com/v4/letter/i/df788c/32.png) [@Ivan](https://discuss.elastic.co/u/Ivan)\
**Post date:** [May 22, 2014, 4:20pm UTC](https://discuss.elastic.co/t/wait-for-yellow-status/17679/1 "2014-05-22T16:20:48Z")

</div>

While doing some tests, I thought I uncovered a bug in the  
cluster-health/wait-for-yellow request. No matter what settings I tried,  
the request would always return immediately with no timeout. I then  
realized that the request is actually something like "wait for AT LEAST  
yellow state". In other words, a GREEN state would satisfy a wait for  
YELLOW state.

The code in question

[https://github.com/elasticsearch/elasticsearch/blob/master/src/main/java/org/elasticsearch/action/admin/cluster/health/TransportClusterHealthAction.java#L132](https://github.com/elasticsearch/elasticsearch/blob/master/src/main/java/org/elasticsearch/action/admin/cluster/health/TransportClusterHealthAction.java#L132)

_response.getStatus().value() \<= request.waitForStatus().value()_

Obviously few people are interested in waiting for when a cluster goes from  
GREEN to YELLLOW, but I am one of those few. I would love to propose a true  
wait-for-yellow (and even red), but it would be difficult to come up with  
an appropriately named call since the waitForYellow is taken and should be  
renamed (breaking code in the process).

I am assuming the current code is a feature and not a bug, in which case  
the documentation should reflect that thinking (willing to fix). But in the  
meantime, how can one be notified if a cluster changes its state from GREEN  
without constant polling?

Cheers,

Ivan

--  
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](mailto:elasticsearch+unsubscribe@googlegroups.com).  
To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CALY%3DcQAfpmsHe%2BfiRZ6\_OD%2BV9bGO\_nsoPPZn8w%3DgWBvJdLGzFg%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CALY%3DcQAfpmsHe%2BfiRZ6_OD%2BV9bGO_nsoPPZn8w%3DgWBvJdLGzFg%40mail.gmail.com).  
For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).

---

<div class="post-metadata">

**Author:** ![Ivan](https://avatars.discourse-cdn.com/v4/letter/i/df788c/32.png) [@Ivan](https://discuss.elastic.co/u/Ivan)\
**Post date:** [May 22, 2014, 7:08pm UTC](https://discuss.elastic.co/t/wait-for-yellow-status/17679/2 "2014-05-22T19:08:21Z")

</div>

And while we are at it, how does one effectively use waitForEvents?

--  
Ivan

On Thu, May 22, 2014 at 9:20 AM, Ivan Brusic [ivan@brusic.com](mailto:ivan@brusic.com) wrote:

> While doing some tests, I thought I uncovered a bug in the  
> cluster-health/wait-for-yellow request. No matter what settings I tried,  
> the request would always return immediately with no timeout. I then  
> realized that the request is actually something like "wait for AT LEAST  
> yellow state". In other words, a GREEN state would satisfy a wait for  
> YELLOW state.
> 
> The code in question
> 
> [https://github.com/elasticsearch/elasticsearch/blob/master/src/main/java/org/elasticsearch/action/admin/cluster/health/TransportClusterHealthAction.java#L132](https://github.com/elasticsearch/elasticsearch/blob/master/src/main/java/org/elasticsearch/action/admin/cluster/health/TransportClusterHealthAction.java#L132)
> 
> _response.getStatus().value() \<= request.waitForStatus().value()_
> 
> Obviously few people are interested in waiting for when a cluster goes  
> from GREEN to YELLLOW, but I am one of those few. I would love to propose a  
> true wait-for-yellow (and even red), but it would be difficult to come up  
> with an appropriately named call since the waitForYellow is taken and  
> should be renamed (breaking code in the process).
> 
> I am assuming the current code is a feature and not a bug, in which case  
> the documentation should reflect that thinking (willing to fix). But in the  
> meantime, how can one be notified if a cluster changes its state from GREEN  
> without constant polling?
> 
> Cheers,
> 
> Ivan

--  
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](mailto:elasticsearch+unsubscribe@googlegroups.com).  
To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CALY%3DcQAWwNErSO\_AdDjy4KuQgPz\_1\_Jx9%2BGndyd3G4QvMvg71Q%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CALY%3DcQAWwNErSO_AdDjy4KuQgPz_1_Jx9%2BGndyd3G4QvMvg71Q%40mail.gmail.com).  
For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).

---

<div class="post-metadata">

**Author:** ![Tyler\_Ball](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/tyler_ball/32/1463_2.png) [@Tyler\_Ball](https://discuss.elastic.co/u/Tyler_Ball)\
**Post date:** [June 23, 2014, 3:46pm UTC](https://discuss.elastic.co/t/wait-for-yellow-status/17679/3 "2014-06-23T15:46:28Z")

</div>

I agree that this seems like a bug (either in the code or the  
documentation). The documentation  
[http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/cluster-health.html](http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/cluster-health.html) says  
it will wait "until the status of the cluster changes to the one provided"  
which is not true.

Our current workflow for a rolling restart checks that the cluster goes  
yellow after a data node leaves. We are using polling to validate this,  
but I would much rather have a blocking wait call.

-T

On Thursday, May 22, 2014 9:20:48 AM UTC-7, Ivan Brusic wrote:

> While doing some tests, I thought I uncovered a bug in the  
> cluster-health/wait-for-yellow request. No matter what settings I tried,  
> the request would always return immediately with no timeout. I then  
> realized that the request is actually something like "wait for AT LEAST  
> yellow state". In other words, a GREEN state would satisfy a wait for  
> YELLOW state.
> 
> The code in question
> 
> [https://github.com/elasticsearch/elasticsearch/blob/master/src/main/java/org/elasticsearch/action/admin/cluster/health/TransportClusterHealthAction.java#L132](https://github.com/elasticsearch/elasticsearch/blob/master/src/main/java/org/elasticsearch/action/admin/cluster/health/TransportClusterHealthAction.java#L132)
> 
> _response.getStatus().value() \<= request.waitForStatus().value()_
> 
> Obviously few people are interested in waiting for when a cluster goes  
> from GREEN to YELLLOW, but I am one of those few. I would love to propose a  
> true wait-for-yellow (and even red), but it would be difficult to come up  
> with an appropriately named call since the waitForYellow is taken and  
> should be renamed (breaking code in the process).
> 
> I am assuming the current code is a feature and not a bug, in which case  
> the documentation should reflect that thinking (willing to fix). But in the  
> meantime, how can one be notified if a cluster changes its state from GREEN  
> without constant polling?
> 
> Cheers,
> 
> Ivan

--  
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](mailto:elasticsearch+unsubscribe@googlegroups.com).  
To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/54c594b9-3780-4ba6-9fd1-6f9609a622d1%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/54c594b9-3780-4ba6-9fd1-6f9609a622d1%40googlegroups.com).  
For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).

---

<div class="post-metadata">

**Author:** ![Ivan](https://avatars.discourse-cdn.com/v4/letter/i/df788c/32.png) [@Ivan](https://discuss.elastic.co/u/Ivan)\
**Post date:** [June 23, 2014, 4:33pm UTC](https://discuss.elastic.co/t/wait-for-yellow-status/17679/4 "2014-06-23T16:33:14Z")

</div>

It appears that the documentation was updated 3 days ago. It now reflects  
the true behavior of the code.

That said, I would still like to see a proper wait for yellow or red.

--  
Ivan

On Mon, Jun 23, 2014 at 8:46 AM, Tyler Ball [tyleraball@gmail.com](mailto:tyleraball@gmail.com) wrote:

> I agree that this seems like a bug (either in the code or the  
> documentation). The documentation  
> [http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/cluster-health.html](http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/cluster-health.html) says  
> it will wait "until the status of the cluster changes to the one provided"  
> which is not true.
> 
> Our current workflow for a rolling restart checks that the cluster goes  
> yellow after a data node leaves. We are using polling to validate this,  
> but I would much rather have a blocking wait call.
> 
> -T
> 
> On Thursday, May 22, 2014 9:20:48 AM UTC-7, Ivan Brusic wrote:
> 
> > While doing some tests, I thought I uncovered a bug in the  
> > cluster-health/wait-for-yellow request. No matter what settings I tried,  
> > the request would always return immediately with no timeout. I then  
> > realized that the request is actually something like "wait for AT LEAST  
> > yellow state". In other words, a GREEN state would satisfy a wait for  
> > YELLOW state.
> > 
> > The code in question
> > 
> > [GitHub - elastic/elasticsearch: Free and Open, Distributed, RESTful Search Engine](https://github.com/elasticsearch/elasticsearch/)  
> > blob/master/src/main/java/org/elasticsearch/action/admin/cluster/health/  
> > TransportClusterHealthAction.java#L132
> > 
> > _response.getStatus().value() \<= request.waitForStatus().value()_
> > 
> > Obviously few people are interested in waiting for when a cluster goes  
> > from GREEN to YELLLOW, but I am one of those few. I would love to propose a  
> > true wait-for-yellow (and even red), but it would be difficult to come up  
> > with an appropriately named call since the waitForYellow is taken and  
> > should be renamed (breaking code in the process).
> > 
> > I am assuming the current code is a feature and not a bug, in which case  
> > the documentation should reflect that thinking (willing to fix). But in the  
> > meantime, how can one be notified if a cluster changes its state from GREEN  
> > without constant polling?
> > 
> > Cheers,
> > 
> > Ivan
> 
> --  
> 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](mailto:elasticsearch+unsubscribe@googlegroups.com).  
> To view this discussion on the web visit  
> [https://groups.google.com/d/msgid/elasticsearch/54c594b9-3780-4ba6-9fd1-6f9609a622d1%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/54c594b9-3780-4ba6-9fd1-6f9609a622d1%40googlegroups.com)  
> [https://groups.google.com/d/msgid/elasticsearch/54c594b9-3780-4ba6-9fd1-6f9609a622d1%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/54c594b9-3780-4ba6-9fd1-6f9609a622d1%40googlegroups.com?utm_medium=email&utm_source=footer)  
> .  
> For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).

--  
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](mailto:elasticsearch+unsubscribe@googlegroups.com).  
To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CALY%3DcQDs\_%3DrZ\_LPVhtKuAa%3D-77amfbNU8cdJVByiteDYy9qcsA%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CALY%3DcQDs_%3DrZ_LPVhtKuAa%3D-77amfbNU8cdJVByiteDYy9qcsA%40mail.gmail.com).  
For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).

---

<div class="post-metadata">

**Author:** ![jprante](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jprante/32/44941_2.png) [@jprante](https://discuss.elastic.co/u/jprante)\
**Post date:** [June 23, 2014, 6:53pm UTC](https://discuss.elastic.co/t/wait-for-yellow-status/17679/5 "2014-06-23T18:53:35Z")

</div>

It would be helpful to add methods like waitForGreenToYellow(),  
waitForYellowToGreen(), waitFor RedToYellow(), waitForYellowToRed(), ...  
for describing exactly the cluster state transitions to wait for.

Jörg

On Mon, Jun 23, 2014 at 6:33 PM, Ivan Brusic [ivan@brusic.com](mailto:ivan@brusic.com) wrote:

> It appears that the documentation was updated 3 days ago. It now reflects  
> the true behavior of the code.
> 
> That said, I would still like to see a proper wait for yellow or red.
> 
> --  
> Ivan
> 
> On Mon, Jun 23, 2014 at 8:46 AM, Tyler Ball [tyleraball@gmail.com](mailto:tyleraball@gmail.com) wrote:
> 
> > I agree that this seems like a bug (either in the code or the  
> > documentation). The documentation  
> > [http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/cluster-health.html](http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/cluster-health.html) says  
> > it will wait "until the status of the cluster changes to the one provided"  
> > which is not true.
> > 
> > Our current workflow for a rolling restart checks that the cluster goes  
> > yellow after a data node leaves. We are using polling to validate this,  
> > but I would much rather have a blocking wait call.
> > 
> > -T
> > 
> > On Thursday, May 22, 2014 9:20:48 AM UTC-7, Ivan Brusic wrote:
> > 
> > > While doing some tests, I thought I uncovered a bug in the  
> > > cluster-health/wait-for-yellow request. No matter what settings I tried,  
> > > the request would always return immediately with no timeout. I then  
> > > realized that the request is actually something like "wait for AT LEAST  
> > > yellow state". In other words, a GREEN state would satisfy a wait for  
> > > YELLOW state.
> > > 
> > > The code in question
> > > 
> > > [GitHub - elastic/elasticsearch: Free and Open, Distributed, RESTful Search Engine](https://github.com/elasticsearch/elasticsearch/)  
> > > blob/master/src/main/java/org/elasticsearch/action/admin/cluster/health/  
> > > TransportClusterHealthAction.java#L132
> > > 
> > > _response.getStatus().value() \<= request.waitForStatus().value()_
> > > 
> > > Obviously few people are interested in waiting for when a cluster goes  
> > > from GREEN to YELLLOW, but I am one of those few. I would love to propose a  
> > > true wait-for-yellow (and even red), but it would be difficult to come up  
> > > with an appropriately named call since the waitForYellow is taken and  
> > > should be renamed (breaking code in the process).
> > > 
> > > I am assuming the current code is a feature and not a bug, in which case  
> > > the documentation should reflect that thinking (willing to fix). But in the  
> > > meantime, how can one be notified if a cluster changes its state from GREEN  
> > > without constant polling?
> > > 
> > > Cheers,
> > > 
> > > Ivan
> > 
> > --  
> > 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](mailto:elasticsearch+unsubscribe@googlegroups.com).  
> > To view this discussion on the web visit  
> > [https://groups.google.com/d/msgid/elasticsearch/54c594b9-3780-4ba6-9fd1-6f9609a622d1%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/54c594b9-3780-4ba6-9fd1-6f9609a622d1%40googlegroups.com)  
> > [https://groups.google.com/d/msgid/elasticsearch/54c594b9-3780-4ba6-9fd1-6f9609a622d1%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/54c594b9-3780-4ba6-9fd1-6f9609a622d1%40googlegroups.com?utm_medium=email&utm_source=footer)  
> > .  
> > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
> 
> --  
> 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](mailto:elasticsearch+unsubscribe@googlegroups.com).  
> To view this discussion on the web visit  
> [https://groups.google.com/d/msgid/elasticsearch/CALY%3DcQDs\_%3DrZ\_LPVhtKuAa%3D-77amfbNU8cdJVByiteDYy9qcsA%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CALY%3DcQDs_%3DrZ_LPVhtKuAa%3D-77amfbNU8cdJVByiteDYy9qcsA%40mail.gmail.com)  
> [https://groups.google.com/d/msgid/elasticsearch/CALY%3DcQDs\_%3DrZ\_LPVhtKuAa%3D-77amfbNU8cdJVByiteDYy9qcsA%40mail.gmail.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/CALY%3DcQDs_%3DrZ_LPVhtKuAa%3D-77amfbNU8cdJVByiteDYy9qcsA%40mail.gmail.com?utm_medium=email&utm_source=footer)  
> .
> 
> For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).

--  
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](mailto:elasticsearch+unsubscribe@googlegroups.com).  
To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CAKdsXoH4ix6O9p1AFzSEJr1\_sUz%2BLAYwFRQ7Oc7FTPkwh3r10w%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAKdsXoH4ix6O9p1AFzSEJr1_sUz%2BLAYwFRQ7Oc7FTPkwh3r10w%40mail.gmail.com).  
For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [July 6, 2017, 1:20am UTC](https://discuss.elastic.co/t/wait-for-yellow-status/17679/6 "2017-07-06T01:20:31Z")

</div>