Update client version & minikube version

[foxish]

Bumping up minikube version (0.12.x -> 0.16.0): Fixes #98
Bumping up kubenetes-client version (2.0.3 -> 2.2.1) Fix for the logging issue in #120

Other seemingly relevant changes on the fabric8 client side:

• okhttp client upgrade from 3.4.1 to 3.6.0
• improvements to watcher code (Use hybrid watch/poll approach in waitUntilReady(). Fix logging of re… fabric8io/kubernetes-client#671)
• Fixes bug in watcher.onClose() not being called.

Tests:
locally passes integration tests

cc @ash211 @mccheah

[ash211]

@foxish I can't quite tell if that fabric8 bump fixes the issue where a Watch's onClose method doesn't get called when it's supposed to. We worked around this in Spark at #121 (comment)

Should I file a ticket in fabric8 for that or did maybe PR 671 handle it?

[foxish]

@ash211 ah yes, I thought the closing was handled by our code, but #120 (comment) indicates it isn't a sufficient fix. Let's hold off on this PR for now, I'll update it after we've fixed it upstream.

[ash211]

Filed upstream as fabric8io/kubernetes-client#674 We'll block merging this PR until there's a released version of kubernetes-client that has a fix for this issue.

[foxish]

@ash211 PTAL, updated the client version to 2.2.0 which was released yesterday and contains the fix to watcher code.

[ash211]

LGTM -- @mccheah ?

I'm really glad you were able to find the onWatch issue @foxish ! And the upstream project was speedy on a release too which is much appreciated

[mccheah]

+1 and merging

[cvpatel]

The integration test for this PR failed after the latest commit. We may want to double check.

�[31m*** RUN ABORTED ***�[0m
�[31m java.lang.NoSuchMethodError: okhttp3.OkHttpClient$Builder.pingInterval(JLjava/util/concurrent/TimeUnit;)Lokhttp3/OkHttpClient$Builder;�[0m
�[31m at io.fabric8.kubernetes.client.utils.HttpClientUtils.createHttpClient(HttpClientUtils.java:115)�[0m
�[31m at io.fabric8.kubernetes.client.BaseClient.(BaseClient.java:45)�[0m
�[31m at io.fabric8.kubernetes.client.DefaultKubernetesClient.(DefaultKubernetesClient.java:116)�[0m
�[31m at org.apache.spark.deploy.kubernetes.integrationtest.minikube.Minikube$.getKubernetesClient(Minikube.scala:105)�[0m
�[31m at org.apache.spark.deploy.kubernetes.integrationtest.KubernetesSuite.beforeAll(KubernetesSuite.scala:72)�[0m
�[31m at org.scalatest.BeforeAndAfterAll$class.beforeAll(BeforeAndAfterAll.scala:187)�[0m
�[31m at org.apache.spark.SparkFunSuite.beforeAll(SparkFunSuite.scala:31)�[0m
�[31m at org.scalatest.BeforeAndAfterAll$class.run(BeforeAndAfterAll.scala:253)�[0m
�[31m at org.apache.spark.deploy.kubernetes.integrationtest.KubernetesSuite.org$scalatest$BeforeAndAfter$$super$run(KubernetesSuite.scala:45)�[0m
�[31m at org.scalatest.BeforeAndAfter$class.run(BeforeAndAfter.scala:241)�[0m
�[31m ...�[0m

[foxish]

Looking into it.

[mccheah]

Looks like an okhttp client conflict, probably because we depend on okhttp ourselves in using Feign. Did Fabric8 upgrade their okhttp version? We should probably match theirs in our own dependencies.

[foxish]

Yes, they updated their client to okHttpClient 3.6 in fabric8io/kubernetes-client#687
Maybe we should use the shader plugin to avoid this sort of conflict?

[mccheah]

If we can shade for a long term fix that would be fantastic - but for a short-term fix can we try pushing our own dependency to match theirs? https://github.com/apache-spark-on-k8s/spark/blob/k8s-support-alternate-incremental/pom.xml#L337

Not sure if upgrading on our end would cause conflicts with Feign though. Might need to bulk upgrade as a short-term fix to synchronize everything.

[ash211]

If we can bump to okHttpClient 3.6 via a feign bump (and feign is the only way we take a transitive dependency on okhttp) then that seems like the way to go

[mccheah]

If I'm understanding Feign correctly, it only pulls in okhttp 3.2.0 even on master: https://github.com/OpenFeign/feign/blob/master/okhttp/build.gradle

We should use Fabric8's transitive dependency, but we'll have to test that this works with Feign.