Wait for yellow status


(Ivan Brusic) #1

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

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.
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.
For more options, visit https://groups.google.com/d/optout.


(Ivan Brusic) #2

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 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

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.
To view this discussion on the web visit 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.


(Tyler Ball) #3

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 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

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


(Ivan Brusic) #4

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 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 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

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.
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?utm_medium=email&utm_source=footer
.
For more options, visit 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.
To view this discussion on the web visit 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.


(Jörg Prante) #5

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 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 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 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

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.
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?utm_medium=email&utm_source=footer
.
For more options, visit 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.
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?utm_medium=email&utm_source=footer
.

For more options, visit 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.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAKdsXoH4ix6O9p1AFzSEJr1_sUz%2BLAYwFRQ7Oc7FTPkwh3r10w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


(system) #6