Kubernetes-client: Checking for Readiness of DeploymentConfig

[scholzj]

In Strimzi, we use Fabric8 to work with DeploymentConfigs. And one of the things we we do with it is checking if the DeploymentConfig is Ready. Normally we would use DeployableScalableResource<DeploymentConfig, DoneableDeploymentConfig> and call isReady(). But after the split of Kubernetes and OpenShift JARs, this method seems to be calling Readiness.isReady(). And because Readiness doesn't support OpenShift resources anymore, it throws an exception that DeploymentConfig is not supported:

java.lang.IllegalArgumentException: Item needs to be one of [Node, Deployment, ReplicaSet, StatefulSet, Pod, ReplicationController], but was: [DeploymentConfig]
    at io.fabric8.kubernetes.client.internal.readiness.Readiness.isReady(Readiness.java:62) ~[io.fabric8.kubernetes-client-4.12.0.jar:?]
    at io.fabric8.kubernetes.client.dsl.base.BaseOperation.isReady(BaseOperation.java:1102) ~[io.fabric8.kubernetes-client-4.12.0.jar:?]
    at io.strimzi.operator.common.operator.resource.DeploymentConfigOperator.isReady(DeploymentConfigOperator.java:120) ~[io.strimzi.operator-common-0.20.0-SNAPSHOT.jar:0.20.0-SNAPSHOT]
    at io.strimzi.operator.common.operator.resource.AbstractResourceOperator.lambda$waitFor$4(AbstractResourceOperator.java:358) ~[io.strimzi.operator-common-0.20.0-SNAPSHOT.jar:0.20.0-SNAPSHOT]
    at io.strimzi.operator.common.Util$1.lambda$handle$0(Util.java:101) ~[io.strimzi.operator-common-0.20.0-SNAPSHOT.jar:0.20.0-SNAPSHOT]
    at io.vertx.core.impl.ContextImpl.lambda$executeBlocking$2(ContextImpl.java:313) ~[io.vertx.vertx-core-3.9.1.jar:3.9.1]
    at io.vertx.core.impl.TaskQueue.run(TaskQueue.java:76) ~[io.vertx.vertx-core-3.9.1.jar:3.9.1]
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
    at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) [io.netty.netty-common-4.1.50.Final.jar:4.1.50.Final]
    at java.lang.Thread.run(Thread.java:834) [?:?]

Since the DeployableScalableResource<DeploymentConfig, DoneableDeploymentConfig> is part of the OpenShift DSL, shouldn't it call OpenShiftReadiness.isReady() instead which would be able to handle DeploymentConfigs as well? I'm right assuming that this is some bug?

[rohanKanojia]

How can I reproduce this? I remember I added a test which actually checks waitUntilReady:
https://github.com/fabric8io/kubernetes-client/blob/579d9728635bb1346b3c4e97eff1cb517e0af249/kubernetes-tests/src/test/java/io/fabric8/openshift/client/server/mock/DeploymentConfigTest.java#L306-L320

[scholzj]

I'm was just looking if I can figure out how to fix it. I can try to create a reproducer as well if you want. But I think the problem with your test is that the waitUntilReady is overriden in OpenShiftOperation and uses OpenShiftReadiness.isReady(resource): https://github.com/fabric8io/kubernetes-client/blob/707ca3b4c38cdf76c33a0f02f517d8c49304b158/openshift-client/src/main/java/io/fabric8/openshift/client/dsl/internal/OpenShiftOperation.java#L106

But isReady() is not overriden and will fall through probably somewhere into BaseOperation

[rohanKanojia]

ohk. I think you're right. I haven't tested this myself but I think adding this to OpenShiftOperation should fix this:

  @Override
  public Boolean isReady() {
    return OpenShiftReadiness.isReady(get());
  }

[scholzj]

Yeah, seems to work fine with the above. Unless you wanna do it your self I can try to open a PR for it.

[rohanKanojia]

I would appreciate if you could create a PR. Apologies for inconvenience caused.

[scholzj]

No worries. It is fairly easy to work around it in Strimzi ... so it doesn't really block us or anything.

[rohanKanojia]

pheww... Now I can have a stress free weekend :laughing: . Thanks a lot for taking care of this :heart:

[scholzj]

Ok, I opened a PR. Please let me know if you have any comments. As I said, we have easy workaround which I already implemented, so as far as Strimzi is concerned no need to do any patch releases or anything. We can easily wait for the next regular release.