Kubernetes-client: Implement waitUntilCondition

[iocanel]

Currently we have the waitUntilReady() functionality, which uses a hybrid approach with polling periodically and watches. This works great but it doesn't cover all our needs. Fro example what about waiting for builds or jobs or anything.

I'd like us to introduce a new method on all resources called waitUntil that will accept and argument, possibly something like a Function<KubernetesResource, Boolean> which is going to return true when the condition is meet.

Then waitUntilReady should be build on top of that.

[piyush-garg]

Hi @iocanel,

Right now we have this functionality in client,

waitUntilReady() {
   waitUntilReady(amount, Timeout);
}

waitUntilReady(amount, TimeUnit) {
   waitTill(timeout or resource get added to queue);
}

So the requirement is something like

waitUntilReady(condition) {
   waitUntillCondition(condition);
}

waitUntilCondition(condition) {
   wait till the condition return true
}

Or

waitUntilReady(condition) {
   wait till waitUntillCondition(conditon) return true;
}

waitUntilCondition(condition) {
   return whether the condition is true or false;
}

Like is the way I am thinking is fine or you have something else as a prototype.

I am assuming that user will provide the condition. This may be wrong also.

Please guide the way this needs to be done.

Thanks

cc @hrishin @rohanKanojia @oscerd

[iocanel]

I would put it slightly different:

At the moment we have:

public T waitUntilReady(long amount, TimeUnit timeUnit) {
    //do wait until ready and then return resource.
}

There are people asking to add things like:

public T waitUntilComplete(long amount, TimeUnit timeUnit) {
    //pretty much do the same thing as waitUntilReady but this time until the state is complete.
}

and

public T waitUntilStarted(long amount, TimeUnit timeUnit) {
    //pretty much do the same thing as waitUntilReady but this time until the job has started
}

So, this issue actually proposes that instead of copying the same mechanism to 3 or more similar methods, to expose it as a generic method:

public void T waitUntilCondition(Function<T, Boolean> condition, long amount, TimeUnit timeunit) {
    //poll & watch until condition applied to the resource returns true.
}

The all the rest waitForSomething methods can internally reuse waitUntilCondition.

For instance watiUntilReady can become:

 public void T waitUntilReady(long amount, TimeUnit timeUnit) {
     waitUntilCondition(r -> Readiniess.isReady(r), amount, timeUnit);
 }

[piyush-garg]

@iocanel Thanks for your input.

As explained above, lambda expressions can be used in Java 8 but our client is in Java 7. Either we need to move to Java 8 or we can use Functional Interface, in that case, the user needs to implement the function, that does not seem to be a good way to do that.

@iocanel Can you provide more thoughts on this or Am I proceeding in some wrong direction?

Thanks

[iocanel]

if we want to stick with java7 we can use the Function class that comes with the kubernetes-model (inside the builder package). Of course, in this case there will be no lambda support.

I'd rather see us moving to java8 though.

[geoand]

I will start working on this

[rhuss]

@iocanel @rohanKanojia wdyt about updating the major version and move to Java 8 ? A bit similar as we do for fmp where we also moved to Java 8 ?

For sure we should skip Java 7 support asap, as they world finally fully embraced Java 8 and is moving quickly to Java 11 as it seems.

[geoand]

@rhuss Hasn't the project already moved to Java 8? I was under the impression that #1168 addressed that concern

[rhuss]

Ah, sorry my bad. haven't checked the date and project state and tried to answer https://github.com/fabric8io/kubernetes-client/issues/989#issuecomment-376996560

I need more coffee ....