opened
mark-nc
username_0
**Describe the bug**
`kubectl get clusterservicestatus` returns a table of CRDs and shows the status accurately, but if you click on a service in the returned table, the detail sidecar status tab displays a table saying the service is `Offline` and the `resource does not exist` due to the fact that the returned CRD YAML is not parsed correctly to find the status.

**Steps to reproduce the behavior**

1. Run command `kubectl get clusterservicestatus`
2. In returned table of services, click on one to get details panel
3. Observe that to populate the details sidecar the command `kubect get clusterservicestatus <clickedServiceName> -o yaml` is run
4. Observe that the details sidecar `Status` tab does not display the service service status and says the service is `Offline` because the `resource does not exist`

**Expected behavior**
The details sidecar should show the same information about the service that the original `kubectl` command displayed in the table.

It looks like this is a result of an unhandled case because this is a CRD.  While it is not expected that the code can decipher every possible CRD that might exist to find out where the CRD defines its resource status, it should do a more reasonable job of handling this as the details Summary tab and YAML tab both indicate that the resource is `Running`.

**Screenshots**
![Screen Shot 2019-09-03 at 4 57 36 PM](https://user-images.githubusercontent.com/51764173/64208230-6226a380-ce6c-11e9-8786-8c1acfa7256c.png)

![Screen Shot 2019-09-03 at 4 59 20 PM](https://user-images.githubusercontent.com/51764173/64208192-4cb17980-ce6c-11e9-9fb7-02669cadea39.png)

![Screen Shot 2019-09-03 at 5 07 37 PM](https://user-images.githubusercontent.com/51764173/64208975-643d3200-ce6d-11e9-9632-a104c302c5f7.png)

**System**

- Kui version: 3.0.14
- Operating system: amd64 Linux (running proxy in docker container)
Details sidecar handling of CRDs needs to handle status better
issue
created
starpit
username_1
thanks for the bug report! would you be able to provide the yaml content? or at least the `.status.conditions` sub-structure?
comment
created
starpit
username_1
the root of the disparity here is that the `kubectl get` table displays whatever kubectl thinks of as the status, because kui, there, only pretty prints (with little interpretation) the ASCII that kubectl emits

whereas for status commands, kui currently has to do a bit more, due to some gaps in kubectl functionality. this is why `k get pod mypod` may show "RUnning" but the sidecar Status table in `k get pod mypod -o yaml` may show "Ready"

there are some nuances that we need to appreciate better. kubectl resources sometimes have a `.status.phase` -- but not always; kubectl resources may also, and also only sometimes, have a `.status.conditions` array. 

when both are present, the latter (conditions array) offers more granularity than the former (phase); i.e. several conditions, each with a distinct message, may be part of one "phase" (such as "Initializing")

in some cases, bugs in kui may result in misinterpreting this information; hence my request for the `.status.conditions` field.  and `.status.phase`, or really the entire `.status` if you can...
comment
created
starpit
username_1
there are some deep mysteries here, to me at least.

how does `k get pods` show “Terminating” for a pod, but if i do a `k get pod thatPod -o yaml`, nothing in that yaml has the string “Terminating”

worse, the `.status.phase` (of the yaml) reads “Running” (despite, simultaneously, `k get pods thatPod` showing “Terminating” for the Status column (of the resultant table)

and the `.status.conditions` array (of the yaml) has only Initialized, Ready, ContainersReady, and PodScheduled entries, all with status:True;

the only minute sign of “terminating” is `.status.containerStatuses`, which has a container whose `lastState` is “terminated” (not “Terminating”, or “terminating”)
comment
created
mark-nc
username_0
Here is the YAML content for that service status.  It shows `Running` just like the Summary tab, but the Status tab still shows `Offline` - `resource does not exist`.

<img width="836" alt="Screen Shot 2019-09-04 at 8 55 06 AM" src="https://user-images.githubusercontent.com/51764173/64256830-33531080-cef2-11e9-8f0f-84b0a6df06f8.png">
comment
created
mark-nc
username_0
I think this may be the point mentioned earlier.  For CRDs there may not be consistent keys used for status/state across any CRD a product or customer might define, but the status/state values may be consistent in terms of status/state that Kubernetes recognizes.  So perhaps searching for a value in the set of known state/status values would be warranted if the status cannot be found in the typical key/value pair.
comment
created
starpit
username_1
thanks. this is one place where kubernetes is a real wild west. there are no standards that enforced on controllers with regards to status
comment
created
mark-nc
username_0
Right...I guess that's why they are called "custom resource definitions", but yes, it would be nice of standardized conventions were defined/followed.
comment
created
showeimer
username_2
Maybe for CRDs just not show the status tab, the user can get the phase/status from the YAML.  The current behavior of defaulting to `Offline` `resource does not exist` will be confusing to the user.
comment
created
starpit
username_1
i'm wondering if we should just drop the Status tab altogether?
comment
created
starpit
username_1
there are other tabs that could provide more valuable content, e.g. Events
comment
created
mark-nc
username_0
I guess I am confused as to how the Summary tab seems to have the right value `Running`.  Is it getting that from some other place than the `.status` structure in the YAML?
comment
created
showeimer
username_2
Summary runs `kubectl get <resource type> <resource name> -n <namespace> -o wide` which returns a table that can be parsed.  The status tab runs `kubectl get <resource type> <resource name> -n <namespace> -o json` which requires Nick to have to know the object mapping to grab the right values from the json structure.  I think It would be fine to drop the status tab because the information is redundant with data in other tabs, and would free up space for more important tabs like Events and Logging.
comment
created
mark-nc
username_0
Sounds good
comment
closed
starpit
username_1
issue
created
starpit
username_1
closing due to #2651, live in 3.0.16
comment