isReady logs a warning when null

[shawkins]

If I do something like: pods().inNamespace...withName...isReady() - I'll see a warning log and a false result when null.

Should isReady return null when the resource is null?

[rohanKanojia]

I'm not sure about this, since this method is named isReady() user's expectations are set to receive a boolean value. I'm not sure if we should return null in this case.

[shawkins]

The interface is already defined as Boolean isReady - if a null result is not possible, it should just be boolean.

[shawkins]

The two proposals would be:

1. return isReady null when the resource is null, with no associated logging. This could be seen by some users as a breaking change, but does conform to the existing interface.
2. Change the interface to boolean isReady and throw a ResourceNotFoundException when the resource is null. This also would be a breaking change, but it would force the caller to handle the null situation rather than logging it.

[manusa]

I don't like the null return value, especially with your depicted scenario.

Users implementing (for whatever reason) a manual version of client.pods().inNamespace...withName...waitUntilReady(...), are probably expecting that statement to return false, since there is no resource available+ready matching that name+namespace.

So (IMHO) I see option 2 as the valid way, but excluding the ResourceNotFoundException

[shawkins]

The root of the problem is:

kubernetes-client/kubernetes-client/src/main/java/io/fabric8/kubernetes/client/internal/readiness/Readiness.java

Line 123 in 74cc63d

logger.warn("{} is not a Readiable resource. It needs to be one of [{}]",

waitUntilReady does a null check before calling isReady(resource)

kubernetes-client/kubernetes-client/src/main/java/io/fabric8/kubernetes/client/dsl/base/BaseOperation.java

Line 962 in b9c5419

return waitUntilCondition(resource -> Objects.nonNull(resource) && getReadiness().isReady(resource), amount, timeUnit);

So you are saying just do the same for isReady() -

kubernetes-client/kubernetes-client/src/main/java/io/fabric8/kubernetes/client/dsl/base/BaseOperation.java

Line 957 in b9c5419

return getReadiness().isReady(get());

And update the interface boolean and javadocs to indicate that missing means not ready - I'm fine with that resolution as well. My impression from some of the logic that we wanted users to be aware that the value was null.

[manusa]

I specifically mentioned the waitUntilReady method because I'm aware that some users from 4.x versions might have a downstream implementation relying on the isReady method. But yes, my opinion is that both methods should be consistent.

I don't know why a Boolean was chosen as the return value instead of boolean in the first place. For me this is semantically confusing (thing are either ready or not), and might complicate things downstream.

Related to:

• Fix #2672: WaitUntilReady for Service resource throws IllegalArgumentException #2796
• Readiness utility should not be flagged as internal #2838
• Readiness utility should be able to support extension #2718
• OpenShiftReadiness is missing isReadinessApplicable #2557
• isReady() from internal package make it publicly available  #2452