-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
VersionInfo contains null data in OpenShift 4.6 #3189
Comments
possibly fixed by #3175 ? |
Not 100% sure since #3175 seems to fix non release OpenShift versions |
I have started a huge comparison between 5.3.1 and 5.4.0 trying to see what's changed regarding the versions but no success so far :( |
ohk, I tried reproducing this and I was able to reproduce this. it's happening on my 4.7.2 cluster as well |
Awesome, did you try with master as well ? At first I thought it was permission issues with the service account, but I'm able to curl "apis/config.openshift.io/v1/clusterversions" within a container... and of course unit tests are working well. It's not so easy for me to play with different versions, as our app now uses Quarkus and it's a bit of #dependencyhell to force the framework using my custom build. |
I think this behavior was introduced by #3049 . We seem to have minor problem in our code which was exposed by this PR. We are calculating openshift 4 version as a fallback when old openshift version apicall fails: Lines 41 to 48 in 1a61f0c
However, in ClusterOperationsImpl we're not checking the response code or whether our response was even successful before assigning to map. Earlier since there was no null check so code used to throw NPE in case of a 404 response body since it won't contain Version data and that NPE was caught by OpenShiftClusterOperationsImpl |
ahah, I knew it was related to NPE somehow, just couldn't verify it, good job @rohanKanojia !!!!! Will you be able to include this as well into the patch release 5.4.1 in time for Quarkus release, please? |
assert response code after getting response from apiServer rather than depending upon fragile null check
assert response code after getting response from apiServer rather than depending upon fragile null check
assert response code after getting response from apiServer rather than depending upon fragile null check
assert response code after getting response from apiServer rather than depending upon fragile null check (cherry picked from commit 062313c)
|
Signed-off-by: Andre Dietisheim <[email protected]>
Signed-off-by: Andre Dietisheim <[email protected]>
Signed-off-by: Andre Dietisheim <[email protected]>
Signed-off-by: Andre Dietisheim <[email protected]>
Signed-off-by: Andre Dietisheim <[email protected]>
Signed-off-by: Andre Dietisheim <[email protected]>
Signed-off-by: Andre Dietisheim <[email protected]>
(#351) * use kubernetes-client 5.7.2 to fix fabric8io/kubernetes-client#3189 * use intellij-common:1.3.0 with same kubernetes-client * depend on intellij-kubernetes with the same kubernetes-client
This issue has been found in
5.4.0
, which is used in Quarkus2.0.0.CR1
. And it is a regression compared to5.3.1
, which was used in Quarkus2.0.0.Alpha3
.With the following code:
In
5.3.1
I see:In
5.4.0
I see:The text was updated successfully, but these errors were encountered: