-
Notifications
You must be signed in to change notification settings - Fork 7k
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
helm status stopped showing containers #6896
Comments
After this change,
|
fixed via #6897 which will be available in 2.16.1. |
This didn't help unfortunately.
|
weird; bbdfe5e is part of the 2.16.1 branch. Perhaps the printer on Kubernetes' end changed again. Did you deploy the app with 2.16.1? Re-opening for further investigation. |
@bacongobbler I have same issue with 2.16.1 My application used to helm v2.14.3, then I upgraded helm to v2.16.1 pods status has been gone |
Deployment, and Service columns have also disappeared. Will 2.16.2 fix ? |
Are you going to build 2.16.2 to fix the issue? |
It should be fix by #7196 |
I'm anxiously awaiting 2.16.2 for #7319, is this issue still in scope for the release? |
I'm still seeing the issue present with the HEAD of
#7319 is irrelevant to this ticket, but yes, It should be in the next patch release. To get a better understanding of the issue here: I'm currently looking into why it keeps breaking, and assess whether we need to replace it with some other API. |
So... kubernetes did indeed break backwards compatibility. You now have to generate a If someone wants to take a closer look at this, I started diving deeper into how |
I have a PR coming with a fix for this. It works. Just need to try and clean up the code some more and figure out how to explain the change. |
Changes to the Kubernetes API server and kubectl libraries caused the status to no longer display when helm status was run for a release. This change restores the status display. Generation of the tables for display was optionally moved server side. A request for the data as a table is made and a kubectl printer for tables can display this data. Kubectl uses this setup and the structure here closely resembles kubectl. kubectl is still able to display objects as tables from prior to server side printing. Server side printing is able to handle non-core resources like CRDs. Note, an extra request is made because table responses cannot be easily transformed into Go objects for Kubernetes types to work with. There is one request to get the resources for display in a table and a second request to get the resources to lookup the related pods. The related pods are now requested as a table as well for display purposes. This is likely part of the larger trend to move features like this server side so that more libraries in more languages can get to the feature. The fix only works for Kubernetes 1.15 and newer. This is when the table functionality was added to the api server. Kubernetes supports the latest 3 minor versions meaning kubectl does the same. It only needs to support back to 1.15 now for table display. In Kubernetes 1.14 kubectl can still display the table information using different printing methods. Closes helm#6896 Signed-off-by: Matt Farina <matt@mattfarina.com>
Changes to the Kubernetes API server and kubectl libraries caused the status to no longer display when helm status was run for a release. This change restores the status display. Generation of the tables for display was optionally moved server side. A request for the data as a table is made and a kubectl printer for tables can display this data. Kubectl uses this setup and the structure here closely resembles kubectl. kubectl is still able to display objects as tables from prior to server side printing. Server side printing is able to handle non-core resources like CRDs. Note, an extra request is made because table responses cannot be easily transformed into Go objects for Kubernetes types to work with. There is one request to get the resources for display in a table and a second request to get the resources to lookup the related pods. The related pods are now requested as a table as well for display purposes. This is likely part of the larger trend to move features like this server side so that more libraries in more languages can get to the feature. The fix only works for Kubernetes 1.15 and newer. This is when the table functionality was added to the api server. Kubernetes supports the latest 3 minor versions meaning kubectl does the same. It only needs to support back to 1.15 now for table display. In Kubernetes 1.14 kubectl can still display the table information using different printing methods. Closes helm#6896 Signed-off-by: Matt Farina <matt@mattfarina.com>
Changes to the Kubernetes API server and kubectl libraries caused the status to no longer display when helm status was run for a release. This change restores the status display. Generation of the tables for display was moved server side. A request for the data as a table is made and a kubectl printer for tables can display this data. Kubectl uses this setup and the structure here closely resembles kubectl. kubectl is still able to display objects as tables from prior to server side printing but only prints limited information. Note, an extra request is made because table responses cannot be easily transformed into Go objects for Kubernetes types to work with. There is one request to get the resources for display in a table and a second request to get the resources to lookup the related pods. The related pods are now requested as a table as well for display purposes. This is likely part of the larger trend to move features like this server side so that more libraries in more languages can get to the feature. Closes helm#6896 Signed-off-by: Matt Farina <matt@mattfarina.com>
PR just landed that fixes this. Should be in the next 2.16 release. |
Changes to the Kubernetes API server and kubectl libraries caused the status to no longer display when helm status was run for a release. This change restores the status display. Generation of the tables for display was moved server side. A request for the data as a table is made and a kubectl printer for tables can display this data. Kubectl uses this setup and the structure here closely resembles kubectl. kubectl is still able to display objects as tables from prior to server side printing but only prints limited information. Note, an extra request is made because table responses cannot be easily transformed into Go objects for Kubernetes types to work with. There is one request to get the resources for display in a table and a second request to get the resources to lookup the related pods. The related pods are now requested as a table as well for display purposes. This is likely part of the larger trend to move features like this server side so that more libraries in more languages can get to the feature. Closes #6896 Signed-off-by: Matt Farina <matt@mattfarina.com> (cherry picked from commit e8396c9)
Couldn't find it in the latest changelog, but:
before upgrade to 2.16, it used to show more detailed information about running pods. Now I need to run kubectl -n get pods -l app=<app-name> to find out if my containers started and passed the Liveness probes. Previously I could just do helm status <release>. Any chances to return to the original behavior?
Output of
helm version
:Client: &version.Version{SemVer:"v2.16.0", GitCommit:"e13bc94621d4ef666270cfbe734aaabf342a49bb", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.16.0", GitCommit:"e13bc94621d4ef666270cfbe734aaabf342a49bb", GitTreeState:"clean"}
Output of
kubectl version
:kubectl version
Client Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.2", GitCommit:"c97fe5036ef3df2967d086711e6c0c405941e14b", GitTreeState:"clean", BuildDate:"2019-10-15T23:41:55Z", GoVersion:"go1.12.10", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"14+", GitVersion:"v1.14.7-eks-e9b1d0", GitCommit:"e9b1d0551216e1e8ace5ee4ca50161df34325ec2", GitTreeState:"clean", BuildDate:"2019-09-21T08:33:01Z", GoVersion:"go1.12.9", Compiler:"gc", Platform:"linux/amd64"}
Cloud Provider/Platform (AKS, GKE, Minikube etc.):
EKS
The text was updated successfully, but these errors were encountered: