refactor(kubernetes): refactor and upgrade kubernetes java client apis and its relevant dependency during upgrade to spring boot 2.6.x #6133
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…s and its relevant dependency during upgrade to spring boot 2.6.x
While upgrading spring boot 2.6.15 and spring cloud 2021.0.8, encounter below errors in clouddriver-kubernetes module during build and test compilation:
```
> Task :clouddriver-kubernetes:compileTestJava FAILED
/clouddriver/clouddriver-kubernetes/src/test/java/com/netflix/spinnaker/clouddriver/kubernetes/artifact/ArtifactReplacerTest.java:33: error: cannot find symbol
import io.kubernetes.client.openapi.models.V1ContainerBuilder;
^
symbol: class V1ContainerBuilder
location: package io.kubernetes.client.openapi.models
/clouddriver/clouddriver-kubernetes/src/test/java/com/netflix/spinnaker/clouddriver/kubernetes/artifact/ArtifactReplacerTest.java:35: error: cannot find symbol
import io.kubernetes.client.openapi.models.V1DeploymentBuilder;
^
symbol: class V1DeploymentBuilder
location: package io.kubernetes.client.openapi.models
/clouddriver/clouddriver-kubernetes/src/test/java/com/netflix/spinnaker/clouddriver/kubernetes/artifact/ArtifactReplacerTest.java:38: error: cannot find symbol
import io.kubernetes.client.openapi.models.V1HorizontalPodAutoscalerBuilder;
^
symbol: class V1HorizontalPodAutoscalerBuilder
location: package io.kubernetes.client.openapi.models
/clouddriver/clouddriver-kubernetes/src/test/java/com/netflix/spinnaker/clouddriver/kubernetes/artifact/ArtifactReplacerTest.java:42: error: cannot find symbol
import io.kubernetes.client.openapi.models.V1ReplicaSetBuilder;
^
symbol: class V1ReplicaSetBuilder
location: package io.kubernetes.client.openapi.models
4 errors
```
```
> Task :clouddriver-kubernetes:compileJava FAILED
/clouddriver/clouddriver-kubernetes/src/main/java/com/netflix/spinnaker/clouddriver/kubernetes/provider/view/KubernetesJobProvider.java:38: error: package org.joda.time does not exist
import org.joda.time.DateTime;
^
1 error
```
```
/clouddriver/clouddriver-kubernetes/src/main/java/com/netflix/spinnaker/clouddriver/kubernetes/model/KubernetesJobStatus.java:71: error: cannot find symbol
this.createdTime = job.getMetadata().getCreationTimestamp().getMillis();
^
symbol: method getMillis()
location: class OffsetDateTime
```
First issue is due to upgrade in kubernetes java client from 11.0.4 to [13.0.2](https://github.com/kubernetes-client/java/blob/master/CHANGELOG.md#1300) brought by spring cloud upgrade to 2021.0.8, which add separate fluent builder classes (and also its generator) to new modules client-java-api-fluent and client-java-api-fluent-gen.
https://repo1.maven.org/maven2/org/springframework/cloud/spring-cloud-dependencies/2021.0.8/spring-cloud-dependencies-2021.0.8.pom
https://repo1.maven.org/maven2/org/springframework/cloud/spring-cloud-kubernetes-dependencies/2.1.8/spring-cloud-kubernetes-dependencies-2.1.8.pom
Since these fluent builder module is not part of java client package pom, so adding explicit dependency of `io.kubernetes:client-java-api-fluent` and pinning the required version.
Second and third issue is due to change in required parameters, from `DateTime` to `OffsetDateTime`, of kubernetes client apis as part of upgrade like for [V1PodCondition.setLastTransitionTime(OffsetDateTime)](https://javadoc.io/static/io.kubernetes/client-java-api/13.0.2/io/kubernetes/client/openapi/models/V1PodCondition.html#setLastTransitionTime-java.time.OffsetDateTime-). Updating the required parameters in order to fix them. And adding the required package.
j-sandy
force-pushed
the
k8s-java-client
branch
from
a8c6800
to
d7b3ad1
Compare
dbyron-sf
approved these changes
Jan 10, 2024
dbyron-sf
added a commit
to dbyron-sf/kork
that referenced
this pull request
Feb 25, 2024
to resolve GHSA-jgvc-jfgh-rjvv No change in dependencies in kork. $ ./gradlew clouddriver-kubernetes:dependencies and ./gradlew orca-clouddriver:dependencies change as follows. before: +--- io.kubernetes:client-java -> 11.0.4 | \--- org.bitbucket.b_c:jose4j:0.7.3 | \--- org.slf4j:slf4j-api:1.7.21 -> 1.7.36 after: +--- io.kubernetes:client-java -> 11.0.4 | \--- org.bitbucket.b_c:jose4j:0.7.3 -> 0.9.3 | \--- org.slf4j:slf4j-api:1.7.21 -> 1.7.36 Note that spinnaker/clouddriver#6133 teaches clouddriver to use version 13.0.2 of io.kubernetes.client-java-api-fluent. It's easy enough to get version 13.0.2 of io.kubernetes.client-java as well. Unfortunately, that only brings the dependency on org.bitbucket.b_c:jose4j from 0.7.3 to 0.7.8 which doesn't resolve the vulnerability. It takes at least [version 18.0.0 of io.kubernetes.java:client-java](https://github.com/kubernetes-client/java/blob/v18.0.0/pom.xml#L153) to get version 0.9.3 of org.bitbucket.b_c:jose4j "naturally", and doing that causes a bunch of compiler errors in clouddriver.
mergify bot
added a commit
to spinnaker/kork
that referenced
this pull request
Feb 27, 2024
…1159) to resolve GHSA-jgvc-jfgh-rjvv No change in dependencies in kork. $ ./gradlew clouddriver-kubernetes:dependencies and ./gradlew orca-clouddriver:dependencies change as follows. before: +--- io.kubernetes:client-java -> 11.0.4 | \--- org.bitbucket.b_c:jose4j:0.7.3 | \--- org.slf4j:slf4j-api:1.7.21 -> 1.7.36 after: +--- io.kubernetes:client-java -> 11.0.4 | \--- org.bitbucket.b_c:jose4j:0.7.3 -> 0.9.3 | \--- org.slf4j:slf4j-api:1.7.21 -> 1.7.36 Note that spinnaker/clouddriver#6133 teaches clouddriver to use version 13.0.2 of io.kubernetes.client-java-api-fluent. It's easy enough to get version 13.0.2 of io.kubernetes.client-java as well. Unfortunately, that only brings the dependency on org.bitbucket.b_c:jose4j from 0.7.3 to 0.7.8 which doesn't resolve the vulnerability. It takes at least [version 18.0.0 of io.kubernetes.java:client-java](https://github.com/kubernetes-client/java/blob/v18.0.0/pom.xml#L153) to get version 0.9.3 of org.bitbucket.b_c:jose4j "naturally", and doing that causes a bunch of compiler errors in clouddriver. Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
While upgrading spring boot 2.6.15 and spring cloud 2021.0.8, encounter below errors in clouddriver-kubernetes module during build and test compilation:
First issue is due to upgrade in kubernetes java client from 11.0.4 to 13.0.2 brought by spring cloud upgrade to 2021.0.8, which add separate fluent builder classes (and also its generator) to new modules client-java-api-fluent and client-java-api-fluent-gen. https://repo1.maven.org/maven2/org/springframework/cloud/spring-cloud-dependencies/2021.0.8/spring-cloud-dependencies-2021.0.8.pom https://repo1.maven.org/maven2/org/springframework/cloud/spring-cloud-kubernetes-dependencies/2.1.8/spring-cloud-kubernetes-dependencies-2.1.8.pom
Since these fluent builder module is not part of java client package pom, so adding explicit dependency of
io.kubernetes:client-java-api-fluentand pinning the required version.Second and third issue is due to change in required parameters, from
DateTimetoOffsetDateTime, of kubernetes client apis as part of upgrade like for V1PodCondition.setLastTransitionTime(OffsetDateTime). Updating the required parameters in order to fix them.