helm status stopped showing containers #6896

mshakhmaykin · 2019-11-06T21:55:33Z

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:

hayorov · 2019-11-07T03:55:13Z

After this change, helm status is ridiculously useless command, it requires to do kubectl get next.

LAST DEPLOYED: Wed Nov  6 20:22:21 2019
NAMESPACE: default
STATUS: DEPLOYED

RESOURCES:
==> v1/ConfigMap
NAME                 AGE
hlf-ord--ord         15h
hlf-orderer-genesis  15h

==> v1/Deployment
NAME     AGE
hlf-ord  15h

==> v1/PersistentVolumeClaim
NAME     AGE
hlf-ord  15h

==> v1/Pod(related)
NAME                      AGE
hlf-ord-655f9d5856-tscnz  2m15s

==> v1/Secret
NAME                   AGE
hlf-orderer-admincert  15h
hlf-orderer-cacert     15h
hlf-orderer-cert       15h
hlf-orderer-key        15h

==> v1/Service
NAME     AGE
hlf-ord  15h

==> v1beta1/Ingress
NAME     AGE
hlf-ord  15h

bacongobbler · 2019-11-07T18:22:08Z

fixed via #6897 which will be available in 2.16.1.

mshakhmaykin · 2019-11-15T15:34:04Z

This didn't help unfortunately.

$ helm version
Client: &version.Version{SemVer:"v2.16.1", GitCommit:"bbdfe5e7803a12bbdf97e94cd847859890cf4050", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.16.1", GitCommit:"bbdfe5e7803a12bbdf97e94cd847859890cf4050", GitTreeState:"clean"}

$ helm status service-app
LAST DEPLOYED: Mon Oct 14 17:40:40 2019
NAMESPACE: default
STATUS: DEPLOYED

RESOURCES:
==> v1/Deployment
NAME        AGE
service-app  31d

==> v1/Pod(related)
NAME                         AGE
service-app-687549b68d-k4wk6  21m
service-app-687549b68d-kz5jp  30d

==> v1/Service
NAME        AGE
service-app  31d

bacongobbler · 2019-11-15T15:44:11Z

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.

thuandt · 2019-11-15T18:15:11Z

@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

cridam · 2019-11-29T16:20:56Z

Deployment, and Service columns have also disappeared. Will 2.16.2 fix ?
i.e
before 2.16.x
==> v1/Service
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
mymicroservice ClusterIP xxx 8443/TCP 25d
after
==> v1/Service
NAME AGE
mymicroservice 25d

liurd · 2019-12-13T05:06:51Z

Are you going to build 2.16.2 to fix the issue?

thuandt · 2019-12-18T06:05:39Z

It should be fix by #7196

bacongobbler · 2019-12-18T07:35:48Z

I don't believe #7196 was intended to fix this issue, however if you can demonstrate that #7196 does indeed fix the issue, we'd love to understand why.

nickdgriffin · 2020-01-17T11:09:24Z

I'm anxiously awaiting 2.16.2 for #7319, is this issue still in scope for the release?

bacongobbler · 2020-03-05T21:53:44Z

I'm still seeing the issue present with the HEAD of dev-v2 with a Kubernetes 1.17 cluster.

I'm anxiously awaiting 2.16.2 for #7319, is this issue still in scope for the release?

#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: helm status relies on the same APIs that kubectl get relies upon. k8s.io/kubernetes has broken backwards compatibility in the past, so it's quite possible it's happened again.

I'm currently looking into why it keeps breaking, and assess whether we need to replace it with some other API.

bacongobbler · 2020-03-06T00:49:36Z

So... kubernetes did indeed break backwards compatibility. You now have to generate a metav1.Table if you want the endpoint to render the same as kubectl get. This broke somewhere around kubernetes 1.16, right when this bug popped up.

If someone wants to take a closer look at this, I started diving deeper into how kubectl get prints objects now in #7728. I don't have time to follow through and fix the issue, but hopefully this helps someone looking at fixing this.

mattfarina · 2020-03-19T01:30:38Z

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 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>

mattfarina · 2020-03-20T16:46:16Z

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)

bacongobbler added bug Categorizes issue or PR as related to a bug. v2.x Issues and Pull Requests related to the major version v2 labels Nov 6, 2019

bacongobbler added this to the 2.16.1 milestone Nov 6, 2019

bacongobbler closed this as completed Nov 7, 2019

bacongobbler reopened this Nov 15, 2019

bacongobbler modified the milestones: 2.16.1, 2.16.2 Nov 15, 2019

bacongobbler mentioned this issue Jan 30, 2020

Helm3 : helm status does not show k8s resource names that were deployed as part of release #5952

Closed

bacongobbler modified the milestones: 2.16.2, 2.16.4 Feb 13, 2020

bacongobbler mentioned this issue Mar 5, 2020

Supporting helm3 to show up resource names that were deployed as part… #7728

Closed

mattfarina self-assigned this Mar 19, 2020

mattfarina mentioned this issue Mar 19, 2020

Restores display of object status when displaying helm status #7785

Merged

mattfarina closed this as completed Mar 20, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

helm status stopped showing containers #6896

helm status stopped showing containers #6896

mshakhmaykin commented Nov 6, 2019 •

edited

hayorov commented Nov 7, 2019 •

edited

bacongobbler commented Nov 7, 2019

mshakhmaykin commented Nov 15, 2019 •

edited

bacongobbler commented Nov 15, 2019 •

edited

thuandt commented Nov 15, 2019

cridam commented Nov 29, 2019

liurd commented Dec 13, 2019

thuandt commented Dec 18, 2019

bacongobbler commented Dec 18, 2019

nickdgriffin commented Jan 17, 2020

bacongobbler commented Mar 5, 2020

bacongobbler commented Mar 6, 2020 •

edited

mattfarina commented Mar 19, 2020 •

edited

mattfarina commented Mar 20, 2020

helm status stopped showing containers #6896

helm status stopped showing containers #6896

Comments

mshakhmaykin commented Nov 6, 2019 • edited

hayorov commented Nov 7, 2019 • edited

bacongobbler commented Nov 7, 2019

mshakhmaykin commented Nov 15, 2019 • edited

bacongobbler commented Nov 15, 2019 • edited

thuandt commented Nov 15, 2019

cridam commented Nov 29, 2019

liurd commented Dec 13, 2019

thuandt commented Dec 18, 2019

bacongobbler commented Dec 18, 2019

nickdgriffin commented Jan 17, 2020

bacongobbler commented Mar 5, 2020

bacongobbler commented Mar 6, 2020 • edited

mattfarina commented Mar 19, 2020 • edited

mattfarina commented Mar 20, 2020

mshakhmaykin commented Nov 6, 2019 •

edited

hayorov commented Nov 7, 2019 •

edited

mshakhmaykin commented Nov 15, 2019 •

edited

bacongobbler commented Nov 15, 2019 •

edited

bacongobbler commented Mar 6, 2020 •

edited

mattfarina commented Mar 19, 2020 •

edited