OCPBUGS-33631: show "Debug container" link for pods with status.phase…

[rhamilto]

… of "Succeeded"

This aligns 4.16 with the behavior in 3.x. See https://github.com/openshift/origin-web-console/blob/c37982397087036321312172282e139da378eff2/app/scripts/directives/resources.js#L33-L53 and note 'Completed' is not a valid value for pod.status.phase (see https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase)

Screen.Recording.2024-05-14.at.9.03.36.AM.mov

[openshift-ci-robot]

@rhamilto: This pull request references Jira Issue OCPBUGS-33631, which is valid. The bug has been moved to the POST state.

3 validation(s) were run on this bug

• bug is open, matching expected state (open)
• bug target version (4.16.0) matches configured target version for branch (4.16.0)
• bug is in the state ASSIGNED, which is one of the valid states (NEW, ASSIGNED, POST)

Requesting review from QA contact:
/cc @yapei

The bug has been updated to refer to the pull request using the external bug tracker.

In response to this:

… of "Succeeded"

This aligns 4.16 with the behavior in 3.x. See https://github.com/openshift/origin-web-console/blob/c37982397087036321312172282e139da378eff2/app/scripts/directives/resources.js#L33-L53 and note 'Completed' is not a valid value for pod.status.phase (see https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase)

Screen.Recording.2024-05-14.at.9.03.36.AM.mov

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[XiyunZhao]

Hi @rhamilto, for those Pods under 'openshift-*' namespace with 'Complete' state, the debug container always failed to launch with different kinds of errors? Do you think it is acceptable?
I think this might confuse the users and make them feel as if there is a bug in the openshift basic pod when they are trying to debug something
eg：

• Pod under openshift-kube-controller-manager, openshift-etcd, openshift-kube-apiserver

  Error: /bin/sh: -=: invalid option Usage: /bin/sh [GNU long option] [option] ... /bin/sh [GNU long option] [option] script-file ... GNU long options: --debug --debugger --dump-po-strings --dump-strings --help --init-file --login --noediting --noprofile --norc --posix --pretty-print --rcfile --rpm-requires --restricted --verbose --version Shell options: -ilrsD or -c command or -O shopt_option (invocation only) -abefhkmnptuvxBCHP or -o option

• Pod under opneshift-operator-lifecycle-manager

  Error: /bin/sh: openshift-operator-lifecycle-manager: No such file or directory

[rhamilto]

Hi @rhamilto, for those Pods under 'openshift-*' namespace with 'Complete' state, the debug container always failed to launch with different kinds of errors? Do you think it is acceptable? I think this might confuse the users and make them feel as if there is a bug in the openshift basic pod when they are trying to debug something eg：

• Pod under openshift-kube-controller-manager, openshift-etcd
  Error: /bin/sh: -=: invalid option Usage: /bin/sh [GNU long option] [option] ... /bin/sh [GNU long option] [option] script-file ... GNU long options: --debug --debugger --dump-po-strings --dump-strings --help --init-file --login --noediting --noprofile --norc --posix --pretty-print --rcfile --rpm-requires --restricted --verbose --version Shell options: -ilrsD or -c command or -O shopt_option (invocation only) -abefhkmnptuvxBCHP or -o option
• Pod under opneshift-operator-lifecycle-manager
  Error: /bin/sh: openshift-operator-lifecycle-manager: No such file or directory
• Pod under openshift-kube-apiserver
  Error: /bin/sh: -=: invalid option Usage: /bin/sh [GNU long option] [option] ... /bin/sh [GNU long option] [option] script-file ... GNU long options: --debug --debugger --dump-po-strings --dump-strings --help --init-file --login --noediting --noprofile --norc --posix --pretty-print --rcfile --rpm-requires --restricted --verbose --version Shell options: -ilrsD or -c command or -O shopt_option (invocation only) -abefhkmnptuvxBCHP or -o option

@jhadvig, WDYT?

[XiyunZhao]

@jhadvig Any thought?

[jhadvig]

@rhamilto @XiyunZhao I think its understandable, cause if you check most of the pods in the mentioned NS, they have a quite a long list of configmaps which are mounted into the pods when created. It looks liked when you create a debug pods those volumes will be missing.
@spadgett thought on this ?

[XiyunZhao]

@jhadvig Thanks for the response, I think you are right. Let's wait for the response from @spadgett

[spadgett]

Are the volume mounts gone because the config maps no longer exist? Or are we simply not mounting the config maps into the debug pod?

Let's compare the behavior here to what happens with oc debug. Can you successfully launch a debug pod using oc?

[rhamilto]

Let's compare the behavior here to what happens with oc debug. Can you successfully launch a debug pod using oc?

Appears so.

❯ oc debug pod/installer-5-ip-10-0-33-186.us-west-1.compute.internal -c installer 
Starting pod/installer-5-ip-10-0-33-186us-west-1computeinternal-debug-7tdvv, command was: cluster-kube-controller-manager-operator installer -v=2 --revision=5 --namespace=openshift-kube-controller-manager --pod=kube-controller-manager-pod --resource-dir=/etc/kubernetes/static-pod-resources --pod-manifest-dir=/etc/kubernetes/manifests --configmaps=kube-controller-manager-pod --configmaps=config --configmaps=cluster-policy-controller-config --configmaps=controller-manager-kubeconfig --optional-configmaps=cloud-config --configmaps=kube-controller-cert-syncer-kubeconfig --configmaps=serviceaccount-ca --configmaps=service-ca --configmaps=recycler-config --secrets=service-account-private-key --optional-secrets=serving-cert --secrets=localhost-recovery-client-token --cert-dir=/etc/kubernetes/static-pod-resources/kube-controller-manager-certs --cert-configmaps=aggregator-client-ca --cert-configmaps=client-ca --optional-cert-configmaps=trusted-ca-bundle --cert-secrets=kube-controller-manager-client-cert-key --cert-secrets=csr-signer
Pod IP: 10.130.0.68
If you don't see a command prompt, try pressing enter.
sh-5.1# 

[rhamilto]

@rhamilto @XiyunZhao I think its understandable, cause if you check most of the pods in the mentioned NS, they have a quite a long list of configmaps which are mounted into the pods when created. It looks liked when you create a debug pods those volumes will be missing.

I don't think missing configmaps is the issue. Based on the errors, I believe the issue is related to the container command. No idea what the fix is though. Am thinking oc debug may provide a the answer, but the Go code is unfamiliar to me.

[spadgett]

The default command for Linux containers in the CLI is /bin/sh

https://github.com/openshift/oc/blob/a5a43b9e6407f8ddf4a73fe995c5eca75a9ac5ab/pkg/cli/debug/debug.go#L70
https://github.com/openshift/oc/blob/a5a43b9e6407f8ddf4a73fe995c5eca75a9ac5ab/pkg/cli/debug/debug.go#L321-L323

although it can be changed by the user.

Are we passing additional args to the command, or just running /bin/sh? The invalid option message is suspicious. Pods can have both a command and args. We should make sure we clear or replace both.

[spadgett]

@rhamilto It looks like we're not clearing the args value?

https://github.com/openshift/console/blob/master/frontend/public/components/debug-terminal.tsx#L44-L51

[rhamilto]

@rhamilto It looks like we're not clearing the args value?

https://github.com/openshift/console/blob/master/frontend/public/components/debug-terminal.tsx#L44-L51

Good catch!

Debug pod created with console:

Debug pod created with oc:

[rhamilto]

@XiyunZhao, I believe the issue with openshift-* namespaced pods is fixed; great catch on that!

Many thanks to @spadgett for the assist in resolving the issue.

Screen.Recording.2024-05-29.at.11.10.19.AM.mov

[rhamilto]

/retest

[rhamilto]

/retest

[rhamilto]

/retest

[openshift-ci]

@rhamilto: all tests passed!

Full PR test history. Your PR dashboard.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

[XiyunZhao]

@rhamilto @spadgett Thank you for all your efforts in discussing and making modifications. Your expertise has been invaluable to me~
This PR has completed the pre-testing, and no other issues were found
/label qe-approved

[openshift-ci-robot]

@rhamilto: This pull request references Jira Issue OCPBUGS-33631, which is invalid:

• expected the bug to target either version "4.17." or "openshift-4.17.", but it targets "4.16.0" instead

Comment /jira refresh to re-evaluate validity if changes to the Jira bug are made, or edit the title of this pull request to link to a different bug.

In response to this:

… of "Succeeded"

This aligns 4.16 with the behavior in 3.x. See https://github.com/openshift/origin-web-console/blob/c37982397087036321312172282e139da378eff2/app/scripts/directives/resources.js#L33-L53 and note 'Completed' is not a valid value for pod.status.phase (see https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase)

Screen.Recording.2024-05-14.at.9.03.36.AM.mov

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[spadgett]

/lgtm

[rhamilto]

/jira refresh

[openshift-ci-robot]

@rhamilto: This pull request references Jira Issue OCPBUGS-33631, which is valid.

3 validation(s) were run on this bug

• bug is open, matching expected state (open)
• bug target version (4.17.0) matches configured target version for branch (4.17.0)
• bug is in the state POST, which is one of the valid states (NEW, ASSIGNED, POST)

Requesting review from QA contact:
/cc @XiyunZhao

In response to this:

/jira refresh

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[rhamilto]

/cherrypick release-4.16

[openshift-cherrypick-robot]

@rhamilto: once the present PR merges, I will cherry-pick it on top of release-4.16 in a new PR and assign it to you.

In response to this:

/cherrypick release-4.16

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: rhamilto, spadgett

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• frontend/OWNERS [rhamilto,spadgett]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[openshift-ci-robot]

@rhamilto: Jira Issue OCPBUGS-33631: All pull requests linked via external trackers have merged:

• openshift/console#13850

Jira Issue OCPBUGS-33631 has been moved to the MODIFIED state.

In response to this:

… of "Succeeded"

This aligns 4.16 with the behavior in 3.x. See https://github.com/openshift/origin-web-console/blob/c37982397087036321312172282e139da378eff2/app/scripts/directives/resources.js#L33-L53 and note 'Completed' is not a valid value for pod.status.phase (see https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase)

Screen.Recording.2024-05-14.at.9.03.36.AM.mov

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[openshift-cherrypick-robot]

@rhamilto: new pull request created: #13914

In response to this:

/cherrypick release-4.16

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.