[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: readiness probes and clustered discovery



We have the basic support for this today - endpoints also contain
unready IPs.  We are adding two constructs that will enable easy
access - a DNS entry that returns all endpoints, no matter whether
they are ready or not, and an annotation on a service that instructs
the endpoints list to contain even unready endpoints.

Those will land in 1.3/3.3

> On May 19, 2016, at 12:59 PM, Luke Meyer <lmeyer redhat com> wrote:
>
> We have a plugin for Elasticsearch to cluster based on looking up endpoints on its clustering service (which runs at separate port 9300 instead of http port 9200). But in order to be among the endpoints on a service, the cluster members have to be considered "up"; so this must occur before they can even discover each other. The result is that there can't be a meaningful readiness probe, and clients of the service get back errors until it is really up.
>
> We could get around this if readiness probes could be honored/ignored by specific services, or if there were some other method of indicating a more nuanced "readiness". If the service for port 9300 could consider the members up once in "Running" state, but the service at port 9200 waited for a readiness check, everything would work out well.
>
> Is this strictly a kubernetes issue? Is there any movement in this direction? It seems like something that many clustered services would benefit from.
> _______________________________________________
> dev mailing list
> dev lists openshift redhat com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]