Bug 1542325

Summary: oc status should not suggest "oc set probe pod"
Product: OpenShift Container Platform Reporter: Xingxing Xia <xxia>
Component: ocAssignee: Maciej Szulik <maszulik>
Status: CLOSED ERRATA QA Contact: Xingxing Xia <xxia>
Severity: low Docs Contact:
Priority: low    
Version: 3.9.0CC: aos-bugs, jokerman, maszulik, mfojtik, mmccomas
Target Milestone: ---   
Target Release: 4.3.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Cause: Pods owned by controllers were not ignored when suggesting probes. Consequence: Pods were appearing in the suggestions. Fix: Ignore pods owned by controllers in probe suggestions. Result: Pods owned by controllers are not showing in the probe suggestions.
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-01-23 11:03:45 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Xingxing Xia 2018-02-06 05:49:23 UTC
Description of problem:
oc status should not suggest "oc set probe pod" because pod updates may not change fields other than a few fields `spec.containers[*].image`, `spec.initContainers[*].image`, `spec.activeDeadlineSeconds` etc. (See below output for more).

Version-Release number of selected component (if applicable):
v3.9.0-0.38.0

How reproducible:
Always

Steps to Reproduce:
1. oc new-app -f https://raw.githubusercontent.com/openshift/origin/master/examples/sample-app/application-template-stibuild.json
2. oc status -v
3. Per the output suggestion, run `oc set probe pod/database-1-deploy --liveness -- echo ok`
4. Check `oc set probe -h`

Actual results:
2. Shows:
...
Info:
  * pod/database-1-deploy has no liveness probe to verify pods are still running.
    try: oc set probe pod/database-1-deploy --liveness ...
  * pod/database-1-hook-mid has no liveness probe to verify pods are still running.
    try: oc set probe pod/database-1-hook-mid --liveness ...
  * pod/database-1-hook-pre has no liveness probe to verify pods are still running.
    try: oc set probe pod/database-1-hook-pre --liveness ...
  * pod/ruby-sample-build-1-build has no liveness probe to verify pods are still running.
    try: oc set probe pod/ruby-sample-build-1-build --liveness ...
  * dc/database has no readiness probe to verify pods are ready to accept traffic or ensure deployment is successful.
    try: oc set probe dc/database --readiness ...
  * dc/database has no liveness probe to verify pods are still running.
    try: oc set probe dc/database --liveness ...
  * dc/frontend has no readiness probe to verify pods are ready to accept traffic or ensure deployment is successful.
    try: oc set probe dc/frontend --readiness ...
  * dc/frontend has no liveness probe to verify pods are still running.
    try: oc set probe dc/frontend --liveness ...
...


3. It fails with message, which is a bit messy and field names in the output are initially upper case.
error: Pod "database-1-deploy" is invalid: spec: Forbidden: pod updates may not change fields other than `spec.containers[*].image`, `spec.initContainers[*].image`, `spec.activeDeadlineSeconds` or `spec.tolerations` (only additions to existing tolerations)
{"Volumes":[{"Name":"...<snipped big paragraph>..."LivenessProbe":
A: {"Exec":{"Command":["echo","ok"]},...<snipped big paragraph>...
B: null,"ReadinessProbe":null...<snipped big paragraph>...

4. It shows: Set or remove a liveness or readiness probe from a pod or pod template

Expected results:
2. Should not show "oc set probe pod" because pod fields (except some, e.g. spec.containers[*].image etc) cannot be changed.
3. `oc set probe pod` message is better to be concise and field names in the output are initially lower case.
4. It should not say it can be used for "a pod", like `oc set env/volumes -h` only mention pod template and don't mention pod.

Additional info:
This bug includes `oc status -v` output, `oc set probe pod` output, `oc set probe -h` output. If separate bugs are needed respectively for them, feel free to tell me to file separate ones

Comment 1 Michal Fojtik 2018-02-06 12:38:30 UTC
Fix: https://github.com/openshift/origin/pull/18470

Setting this as low priority as this is just an output/help problem and not a regression. Definitely not blocking 3.9 release.

Comment 2 Xingxing Xia 2018-04-19 08:46:25 UTC
PR merged, now it does not suggest for controller-owned pod, but still for standalone pod:
# oc version
oc v3.10.0-0.22.0
kubernetes v1.10.0+b81c8f8
features: Basic-Auth GSSAPI Kerberos SPNEGO

Server https://MASTER:8443
openshift v3.10.0-0.22.0
kubernetes v1.10.0+b81c8f8

# oc status --suggest
...
Info:
  * pod/hello-openshift has no liveness probe to verify pods are still running.
    try: oc set probe pod/hello-openshift --liveness ...
...

Comment 5 Xingxing Xia 2019-10-25 09:05:25 UTC
Mistake : ) above was intended to be pasted in bug 1540560 verification.
Verified in oc of openshift-clients-4.3.0-201910240917.git.1.265278a.el7.x86_64, now standalone pod has no such suggestion:
$ oc status --suggest
In project xxia-proj on server https://$SERVER:6443

svc/hello-daemonset - 172.30.10.215:8080
  daemonset/hello-daemonset manages openshift/hello-openshift
    generation #1 running for 9 minutes - 2 pods

pod/hello-openshift runs openshift/hello-openshift

Info:
  * daemonset/hello-daemonset has no liveness probe to verify pods are still running.
    try: oc set probe daemonset/hello-daemonset --liveness ...

Comment 7 errata-xmlrpc 2020-01-23 11:03:45 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:0062