search

redhat-developer / intellij-kubernetes

IntelliJ Kubernetes plugin
https://plugins.jetbrains.com/plugin/15921-kubernetes-by-red-hat
Eclipse Public License 2.0
20 stars 20 forks source link

Support Kubernetes 1.22.0 #266

Closed adietish closed 3 years ago

adietish commented 3 years ago

Steps:

  1. ASSERT: use latest minikube with --kubernetes-version=v1.22.1
  2. ASSERT: make sure that you have custorm resource definitions
  3. EXEC: in tool window/resource tree: unfold "Custom Resources"

Result: "Custom Resources" has no children In the log you'll find the following:

2021-09-17 22:35:12,255 [  31807]   WARN - .ResourceWatch$ResourceWatcher - Could not watch resource(s) ResourceKind(version=apiextensions/v1beta1, clazz=class io.fabric8.kubernetes.api.model.apiextensions.v1beta1.CustomResourceDefinition, kind=CustomResourceDefinition). 
io.fabric8.kubernetes.client.KubernetesClientException: the server could not find the requested resource
    at io.fabric8.kubernetes.client.dsl.internal.WatcherWebSocketListener.onFailure(WatcherWebSocketListener.java:74)
    at okhttp3.internal.ws.RealWebSocket.failWebSocket(RealWebSocket.java:571)
    at okhttp3.internal.ws.RealWebSocket$2.onResponse(RealWebSocket.java:198)
    at okhttp3.RealCall$AsyncCall.execute(RealCall.java:203)
    at okhttp3.internal.NamedRunnable.run(NamedRunnable.java:32)
    at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
    at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
    at java.base/java.lang.Thread.run(Thread.java:834)
    Suppressed: java.lang.Throwable: waiting here
        at io.fabric8.kubernetes.client.utils.Utils.waitUntilReady(Utils.java:164)
        at io.fabric8.kubernetes.client.utils.Utils.waitUntilReadyOrFail(Utils.java:175)
        at io.fabric8.kubernetes.client.dsl.internal.WatcherWebSocketListener.waitUntilReady(WatcherWebSocketListener.java:120)
        at io.fabric8.kubernetes.client.dsl.internal.WatchConnectionManager.waitUntilReady(WatchConnectionManager.java:80)
        at io.fabric8.kubernetes.client.dsl.base.BaseOperation.watch(BaseOperation.java:681)
        at io.fabric8.kubernetes.client.dsl.base.BaseOperation.watch(BaseOperation.java:656)
        at io.fabric8.kubernetes.client.dsl.base.BaseOperation.watch(BaseOperation.java:88)
        at com.redhat.devtools.intellij.kubernetes.model.resource.NonNamespacedResourceOperator.watchAll(NonNamespacedResourceOperator.kt:49)
        at com.redhat.devtools.intellij.kubernetes.model.context.ActiveContext$watch$1.invoke(ActiveContext.kt:269)
        at com.redhat.devtools.intellij.kubernetes.model.context.ActiveContext$watch$1.invoke(ActiveContext.kt:47)
        at com.redhat.devtools.intellij.kubernetes.model.ResourceWatch$WatchOperation.run(ResourceWatch.kt:136)
        at com.redhat.devtools.intellij.kubernetes.model.ResourceWatch$WatchOperationsRunner.run(ResourceWatch.kt:120)
        at java.base/java.util.concurrent.ForkJoinTask$AdaptedRunnableAction.exec(ForkJoinTask.java:1407)
        at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
        at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020)
        at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656)
        at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594)
        at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:177)
adietish commented 3 years ago

turns out that quite some apis were deprecated:

adietish commented 3 years ago

Plugin is loading CustomResourceDefinitions in version apiextensions/v1beta1 which was removed in kubernetes 1.22.1. Only apiextensions/v1 is now available.

package com.redhat.devtools.intellij.kubernetes.model.resource.kubernetes.custom

...
import io.fabric8.kubernetes.api.model.apiextensions.v1beta1.CustomResourceDefinition
...

object CustomResourceOperatorFactory {
adietish commented 3 years ago

the following apis were removed:

adietish commented 3 years ago

@jeffmaury, @lstocchi: v1 for CustomResourceDefinition was introduced ~2y ago. I'd opt for supporting in v1 only, dropping v1beta1. Thoughts?

@jeffmaury, @lstocchi: v1 for Ingress was introduced ~1.2y ago. I'd still opt for offering v1 only, dropping v1beta1. Arguable though.

adietish commented 3 years ago

the next release with removal of deprecated APIs is 1.25. For us it'll affect Endpoint, CronJob which were introduced in v1 per 1.21.

lstocchi commented 3 years ago

@jeffmaury, @lstocchi: I'd opt for supporting CustomResourceDefinition in v1 only, dropping v1beta1. Thoughts?

@jeffmaury, @lstocchi: v1 for Ingress was introduced ~1.2y ago. I'd still opt for offering v1 only, dropping v1beta1. Arguable though.

I agree with you in both cases. Supporting v1 is enough imo, if k8s deprecates them there is no reason for the plugin to support them. Then you can still access all existing old resources with v1.

adietish commented 3 years ago

I agree with you in both cases. Supporting v1 is enough imo, if k8s deprecates them there is no reason for the plugin to support them. Then you can still access all existing old resources with v1.

+1 but then we'd drop out support for older kube cluster which would not support v1. With 1.2y for Ingress and 2y for crds I'd think that this is good enough. The alternative would be to impl a discovery where we'd have to see what versions are available and pick the latest one that's supported for the given cluster. Imho not worth the effort.

lstocchi commented 3 years ago

+1 but then we'd drop out support for older kube cluster which would not support v1. With 1.2y for Ingress and 2y for crds I'd think that this is good enough. The alternative would be to impl a discovery where we'd have to see what versions are available and pick the latest one that's supported for the given cluster. Imho not worth the effort.

Do you know which k8s versions are customers using though telemetry? That would help i guess

adietish commented 3 years ago

+1 but then we'd drop out support for older kube cluster which would not support v1. With 1.2y for Ingress and 2y for crds I'd think that this is good enough. The alternative would be to impl a discovery where we'd have to see what versions are available and pick the latest one that's supported for the given cluster. Imho not worth the effort.

Do you know which k8s versions are customers using though telemetry? That would help i guess

Good point. I looked into current telemetry data (only openshift and tekton so far) which shows a limited sample with the majority of users having no kubernetes version. Among the ones with a version the majority is >= 1.19. I doubt this data has any real life significance, it is far too little. A similar picture can be observed with vscode tekton users.

adietish commented 3 years ago

@jeffmaury Here are the kubernetes versions that the openshift versions ship: image

jeffmaury commented 3 years ago

According to this: https://access.redhat.com/support/policy/updates/openshift you can start from 4.6

adietish commented 3 years ago

@jeffmaury matches my understanding, 4.6 going EOL with the upcoming release of 4.9. image 4.6 is kubernetes 1.19 which is the minimum version I support with my PRs. Makes me think that we're good to go.