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 <[email protected]> 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 > [email protected] > http://lists.openshift.redhat.com/openshiftmm/listinfo/dev _______________________________________________ dev mailing list [email protected] http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
