Bug 1542325 - oc status should not suggest "oc set probe pod"
Summary: oc status should not suggest "oc set probe pod"
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: oc
Version: 3.9.0
Hardware: Unspecified
OS: Unspecified
low
low
Target Milestone: ---
: 4.3.0
Assignee: Maciej Szulik
QA Contact: Xingxing Xia
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-02-06 05:49 UTC by Xingxing Xia
Modified: 2020-01-23 11:04 UTC (History)
5 users (show)

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.
Clone Of:
Environment:
Last Closed: 2020-01-23 11:03:45 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github openshift oc pull 116 0 'None' closed Bug 1542325: ignore pods when giving liveness suggestions 2020-10-27 20:37:27 UTC
Red Hat Product Errata RHBA-2020:0062 0 None None None 2020-01-23 11:03:59 UTC

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


Note You need to log in before you can comment on or make changes to this bug.