Does not shrink like it used to for smaller screens

e.g. Trying to select a kube config file - if the permissions are wrong, we don't show an error, yet we don't allow the user to connect

Frontent Deployment type

• Cloud Foundry Application (cf push)
• Kubernetes, using a helm chart
• Docker, using docker compose
• Docker, single container deploying all components
• npm run start
• Other (please specify below)

Backend (portal-proxy) Deployment type

• Cloud Foundry Application (cf push)
• Kubernetes, using a helm chart
• Docker, using docker compose
• Docker, single container deploying all components
• Other (please specify below)

Expected behaviour

Actual behaviour

Steps to reproduce the behavior

Log output covering before error and any error statements

Insert log hereCopy

Detailed Description

Context

Possible Implementation

Filing this against the SUSE version, but possibly also appliccable to upstream.

Currently we see:

SUSE Stratos
Cloud Foundry
Console
Use SUSE Stratos to develop, compose, and manage Cloud Foundry workloads.

We should consider changing this to include Kubernetes workloads. Suggest:

SUSE Stratos
Console
Use SUSE Stratos to manage Cloud Foundry and Kubernetes systems and workloads.

Open to other messaging ideas. We basically just want to give people an idea what they'll be able to do once they log in.

Frontent Deployment type

• Cloud Foundry Application (cf push)
• Kubernetes, using a helm chart
• Docker, using docker compose
• Docker, single container deploying all components
• npm run start
• Other (please specify below)
  Azure AKS using the kubernetes LoadBalancer

Backend (portal-proxy) Deployment type

• Cloud Foundry Application (cf push)
• Kubernetes, using a helm chart
• Docker, using docker compose
• Docker, single container deploying all components
• Other (please specify below)
  Azure AKS using the kubernetes LoadBalancer

Expected behaviour

Stratos is deployed using the same scf-config-values.yaml file as for uaa, and scf. It should get a LoadBalanced public IP automatically, when external_ips is missing and loadbalanced is true:

example scf-config-values.yaml:

secrets:
    CLUSTER_ADMIN_PASSWORD: changeme
    UAA_ADMIN_CLIENT_SECRET: uaa-admin-client-secret

env:
    DOMAIN: svlb.susecap.net
    UAA_HOST: uaa.svlb.susecap.net
    UAA_PORT: 2793
    GARDEN_ROOTFS_DRIVER: "overlay-xfs"

kube:
    storage_class:
        persistent: "default"
        shared: "shared"

    registry:
       hostname: "staging.registry.howdoi.website"
       username: ""
       password: ""
    organization: "splatform"

    auth: none

services:
  loadbalanced: true

There should be console-ui-ext-public like with:

diego-access-public    LoadBalancer   10.0.22.62     40.118.56.197    2222:32044/TCP

Actual behaviour

console-ui-ext has no EXTERNAL IP:

> kubectl --namespace stratos get svc console-ui-ext
NAME             TYPE       CLUSTER-IP   EXTERNAL-IP   PORT(S)                      AGE
console-ui-ext   NodePort   10.0.34.56   <none>        80:32127/TCP,443:30718/TCP   19m

Steps to reproduce the behavior

see https://trello.com/c/sQGhnAwJ

Log output covering before error and any error statements

Insert log hereCopy

Detailed Description

Context

Possible Implementation

Frontend Deployment type

• Cloud Foundry Application (cf push)
• Kubernetes, using a helm chart
• Docker, using docker compose
• Docker, single container deploying all components
• npm run start
• Other (please specify below)
  CaaSP3

Backend (Jet Stream) Deployment type

• Cloud Foundry Application (cf push)
• Kubernetes, using a helm chart
• Docker, using docker compose
• Docker, single container deploying all components
• Other (please specify below)
  CaaSP3

Expected behaviour

> helm upgrade --recreate-pods console helm/console --values scf-config-values.yaml works

Actual behaviour

Error: UPGRADE FAILED - see logs

Steps to reproduce the behavior

Have Stratos-2.1.0 installed and try to upgrade to Stratos-2.2.0-b86ec46-cap:
> helm upgrade --recreate-pods console helm/console --values scf-config-values.yaml

Log output covering before error and any error statements

> helm upgrade --recreate-pods console helm/console --values scf-config-values.yaml
Error: UPGRADE FAILED: Deployment.apps "console-mariadb" is invalid: spec.template.metadata.labels: Invalid value: map[string]string{"app.kubernetes.io/instance":"console", "app.kubernetes.io/name":"stratos", "app.kubernetes.io/component":"console-mariadb", "app.kubernetes.io/version":"2.1.1", "helm.sh/chart":"console-2.2.0-b86ec46-cap"}: `selector` does not match template `labels` && StatefulSet.apps "console" is invalid: spec.template.metadata.labels: Invalid value: map[string]string{"app.kubernetes.io/component":"console", "helm.sh/chart":"console-2.2.0-b86ec46-cap", "app.kubernetes.io/instance":"console", "app.kubernetes.io/name":"stratos", "app.kubernetes.io/version":"2.1.1"}: `selector` does not match template `labels`

.. in the endpoints table

Frontend Deployment type

• Cloud Foundry Application (cf push)
• Kubernetes, using a helm chart
• Docker, using docker compose
• Docker, single container deploying all components
• npm run start
• Other (please specify below)
  CaaSP3

Backend (Jet Stream) Deployment type

• Cloud Foundry Application (cf push)
• Kubernetes, using a helm chart
• Docker, using docker compose
• Docker, single container deploying all components
• Other (please specify below)
  CaaSP3

Expected behaviour

Stratos shows an error message if the token refresh request failed.

Actual behaviour

The Endpoint is listed as connected, but the Kubernetes Menu doesn't show or update any data.

Steps to reproduce the behavior

Register kubernetes endpoint and e.g. use the same kubeconfig from the cli until Stratos can't refresh the Kubernetes data anymore.

Log output covering before error and any error statements

kubectl logs console-0 proxy -n stratos snippet

ERRO[Tue Nov 13 12:42:47 UTC 2018] Error performing http request - response: &{400 Bad Request 400 HTTP/1.1 1 1 map[Content-Length:[121] Content-Type:[application/json] Date:[Tue, 13 Nov 2018 12:42:47 GMT]] 0xc42053b380 121 [] false false map[] 0xc420467600 0xc4202b4420}, error: <nil> 
WARN[Tue Nov 13 12:42:47 UTC 2018] <nil>+                                       
INFO[Tue Nov 13 12:42:47 UTC 2018] Token refresh request failed: Error: <nil>
Status: 400
Response: {"error":"invalid_request","error_description":"Refresh token is invalid or has already been claimed by another client."} 
WARN[Tue Nov 13 12:42:47 UTC 2018] Passthrough response: URL: https://f81.suse.de:6443/api/v1/pods, Status Code: 500, Status: Error proxing request, Content Type: Unknown, Length: -1 
WARN[Tue Nov 13 12:42:47 UTC 2018] Couldn't refresh token for CNSI with GUID XcksQeT30dPLsVyf7s0O0NqtATE 
Request: [2018-11-13T12:42:47Z] Remote-IP:"172.16.4.1" Method:"GET" Path:"/v1/proxy/api/v1/pods" Status:200 Latency:16.565414ms Bytes-In:0 Bytes-Out:182
INFO[Tue Nov 13 12:42:48 UTC 2018] {"ClientID":"velum","ClientSecret":"74c7d1c4-1e62-4c23-8e2d-867ce22133f2","IssuerURL":"https://f81.suse.de:32000"} 
INFO[Tue Nov 13 12:42:48 UTC 2018] &{velum 74c7d1c4-1e62-4c23-8e2d-867ce22133f2 https://f81.suse.de:32000} 
INFO[Tue Nov 13 12:42:48 UTC 2018] velum                                        
INFO[Tue Nov 13 12:42:48 UTC 2018] 74c7d1c4-1e62-4c23-8e2d-867ce22133f2

Services view did not show all of the Metrics services - not all services have the ‘release’ label

At the moment the kube summary and helm release charts have no way to be refreshed other than refreshing the whole page. Need some kind of refresh button/pattern

K8S -> Namespace -> Pod -> Pod Metrics has extra space at the top of the view

Long annotations missing text inside the pills

K8S Node view - annotations card has one tooltip for entire card - also for Labels.

On a system without metrics, go the K8S view.

Refresh the browser to reload the app.

Click on a node - the Metrics tab will appear

Namespace Pods view - check pagination key - if you go to a node pod list and then to a namespace pod list - you’ll only see pods from the first node

Frontent Deployment type

• Cloud Foundry Application (cf push)
• Kubernetes, using a helm chart
• Docker, using docker compose
• Docker, single container deploying all components
• npm run start
• Other (please specify below)

Backend (portal-proxy) Deployment type

• Cloud Foundry Application (cf push)
• Kubernetes, using a helm chart
• Docker, using docker compose
• Docker, single container deploying all components
• Other (please specify below)

Expected behaviour

Actual behaviour

Steps to reproduce the behavior

Log output covering before error and any error statements

Insert log hereCopy

Detailed Description

Context

Possible Implementation

Routes table - attached app pills - green text on grey not easy to read

See: https://www.suse.com/documentation/cloud-application-platform-1/book_cap_deployment/data/sec_cap_stratos-prod.html

• Nodes tables
  • Convert Capacity Memory value to human readable short string
• Node Metrics - Legend/Series label
  • Shows duplicates due to labels missing container details. Also results in 13 shown in legend vs 30 shown in 'hover over' window. Think the conclusion was to show metrics per container and confirm legend area scrolls correctly
• Filter out Container POD everywhere except for the 'Network IO' chart (any others?)
• Summary cards showing total CPU time in seconds need to round up to hours, days, etc. Moment should be able to do this using their Durations object
• Namespace--> applications table needs to show additional version column
• Docs needed to describe different methods to connect to K8 endpoint
• Upstream but fix here to prove out... void space is shown on pages where there are no tabs (pods-->metrics)
• Upstream but mostly visible here.... Handle pagination from different api's rather than using cf params

Errors making requests don't get reflected in the tables - they just say 'There are no entries'.

We should improve this to say there was an error fetching nodes (for example)

We could use a similar presentation to other places, where we show an error icon and message

In a lo of places we're using 'object => object.name' and in most cases this returns undefined. It looks like a bad copy paste.

Customer request (placeholder). Detail TBA

• For failed cf requests we show a banner & warning in endpoint table
• When metrics or K8 requests fail need to do the same

K8S Node View - tidy up card layout - remove summary card and improve layout. Can we show capacity?

K8S CPU Usage - round values in hover tooltip - but remember this shows seconds not percentage

• there's a few requests that return responses for multiple endpoints
• need to raise individual errors when an endpoint fails as per api.effect

• install a chart with a new namespace
• when deleting the chart optionally delete namespace as well

Copy pasta backstory from SUSE/doc-cap#351

Reported internally some time ago during a CaaSP upgrade, afterwards CAP stopped responding.

Since there's a bit of a race condition at play, it looks like Stratos came up first and grabbed port 80. The operator changed the NodePort of susecf-console-ui-ext to be on port 8080 instead of port 80 and everything worked again.

On the docs end we've been asked to document to not use port 80 by default when using load balancers with Stratos. This has been added and works as a short-term fix, but would be better in the long-term if changed on the Stratos end so users are not doing these additional steps.

Only when build with aot and a prod build.

Side nav gets hidden.
Top navigation header has incorrect vertical spacing - table renders underneath tabs

There is a series per CPU, identified bymetric.cpu

Frontent Deployment type

• Cloud Foundry Application (cf push)
• Kubernetes, using a helm chart
• Docker, using docker compose
• Docker, single container deploying all components
• npm run start
• Other (please specify below)
  Console 2.1.0 with CAP 1.2.1

Backend (Jet Stream) Deployment type

• Cloud Foundry Application (cf push)
• Kubernetes, using a helm chart
• Docker, using docker compose
• Docker, single container deploying all components
• Other (please specify below)
  UAA/CF 2.13.3 on CaaSP3 (NFS storage)

Expected behaviour

• Goto https://<domain>:8443/cloud-foundry, select "Organizations" and create org 'suseqa'
• Click on org 'suseqa', select "Spaces" and create space 'susetest'

Actual behaviour

• After clicking org 'suseqa' and selecting sapces, "'Cloud Foundry > suseqa' Spaces" loads forever.

• From here on any other menu, e.g. "Services" loads forever, too, even when you return to "Cloud Foundry" - it seems like not being authenticated with the endpoint anymore

• Simply reloading the browser page on a page that "hangs" fixes the issue.

Steps to reproduce the behavior

Log output covering before error and any error statements

Unfortunately I was not able to see any error logged:

Request: [2018-10-01T11:57:11Z] Remote-IP:"172.16.4.0" Method:"GET" Path:"/v1/auth/session/verify" Status:401 Latency:65.157µs Bytes-In:0 Bytes-Out:43
INFO[Mon Oct  1 11:57:17 UTC 2018] Found existing cloud foundry endpoint matching https://api.10.160.64.141.omg.howdoi.website. Will not auto-register 
INFO[Mon Oct  1 11:57:17 UTC 2018] Determining if user should auto-connect to https://api.10.160.64.141.omg.howdoi.website. 
INFO[Mon Oct  1 11:57:17 UTC 2018] Yes, user should auto-connect to auto-registered cloud foundry https://api.10.160.64.141.omg.howdoi.website. 
INFO[Mon Oct  1 11:57:17 UTC 2018] Auto-connecting to the auto-registered endpoint with credentials 
INFO[Mon Oct  1 11:57:17 UTC 2018] CloudFoundry Connect...                      
Request: [2018-10-01T11:57:18Z] Remote-IP:"172.16.4.0" Method:"POST" Path:"/v1/auth/login/uaa" Status:200 Latency:532.690164ms Bytes-In:32 Bytes-Out:90
Request: [2018-10-01T11:57:18Z] Remote-IP:"172.16.4.0" Method:"GET" Path:"/v1/auth/session/verify" Status:200 Latency:5.004533ms Bytes-In:0 Bytes-Out:2668
Request: [2018-10-01T11:57:18Z] Remote-IP:"172.16.4.0" Method:"GET" Path:"/v1/info" Status:200 Latency:3.92472ms Bytes-In:0 Bytes-Out:2668
Request: [2018-10-01T11:57:18Z] Remote-IP:"172.16.4.0" Method:"GET" Path:"/v1/proxy/v2/apps" Status:200 Latency:38.508909ms Bytes-In:0 Bytes-Out:115
Request: [2018-10-01T11:57:18Z] Remote-IP:"172.16.4.0" Method:"GET" Path:"/v1/proxy/v2/organizations" Status:200 Latency:104.229272ms Bytes-In:0 Bytes-Out:3900
Request: [2018-10-01T11:57:24Z] Remote-IP:"172.16.4.0" Method:"GET" Path:"/v1/proxy/v2/shared_domains" Status:200 Latency:14.122311ms Bytes-In:0 Bytes-Out:431
Request: [2018-10-01T11:57:24Z] Remote-IP:"172.16.4.0" Method:"GET" Path:"/v1/proxy/v2/info" Status:200 Latency:27.536657ms Bytes-In:0 Bytes-Out:758
Request: [2018-10-01T11:57:24Z] Remote-IP:"172.16.4.0" Method:"GET" Path:"/v1/proxy/v2/organizations" Status:200 Latency:36.196932ms Bytes-In:0 Bytes-Out:1627
Request: [2018-10-01T11:57:24Z] Remote-IP:"172.16.4.0" Method:"GET" Path:"/v1/proxy/v2/organizations" Status:200 Latency:74.945893ms Bytes-In:0 Bytes-Out:6016
Request: [2018-10-01T11:57:24Z] Remote-IP:"172.16.4.0" Method:"GET" Path:"/v1/proxy/v2/users" Status:200 Latency:107.604265ms Bytes-In:0 Bytes-Out:1959
Request: [2018-10-01T11:57:29Z] Remote-IP:"172.16.4.0" Method:"GET" Path:"/v1/proxy/v2/organizations/9aaa261d-1236-4cda-8e11-ead1002512c0/users" Status:200 Latency:56.787312ms Bytes-In:0 Bytes-Out:115
Request: [2018-10-01T11:57:29Z] Remote-IP:"172.16.4.0" Method:"GET" Path:"/v1/proxy/v2/organizations" Status:200 Latency:84.159799ms Bytes-In:0 Bytes-Out:1627
Request: [2018-10-01T11:57:36Z] Remote-IP:"172.16.4.0" Method:"GET" Path:"/v1/auth/session/verify" Status:200 Latency:13.410628ms Bytes-In:0 Bytes-Out:2668
Request: [2018-10-01T11:57:36Z] Remote-IP:"172.16.4.0" Method:"GET" Path:"/v1/info" Status:200 Latency:7.68204ms Bytes-In:0 Bytes-Out:2668
Request: [2018-10-01T11:57:36Z] Remote-IP:"172.16.4.0" Method:"GET" Path:"/v1/proxy/v2/shared_domains" Status:200 Latency:15.229401ms Bytes-In:0 Bytes-Out:431
Request: [2018-10-01T11:57:36Z] Remote-IP:"172.16.4.0" Method:"GET" Path:"/v1/proxy/v2/organizations/9aaa261d-1236-4cda-8e11-ead1002512c0/spaces" Status:200 Latency:29.989988ms Bytes-In:0 Bytes-Out:1448
Request: [2018-10-01T11:57:36Z] Remote-IP:"172.16.4.0" Method:"GET" Path:"/v1/proxy/v2/organizations/9aaa261d-1236-4cda-8e11-ead1002512c0" Status:200 Latency:40.100252ms Bytes-In:0 Bytes-Out:3820
Request: [2018-10-01T11:57:36Z] Remote-IP:"172.16.4.0" Method:"GET" Path:"/v1/proxy/v2/organizations" Status:200 Latency:29.595215ms Bytes-In:0 Bytes-Out:1627
Request: [2018-10-01T11:57:36Z] Remote-IP:"172.16.4.0" Method:"GET" Path:"/v1/proxy/v2/users" Status:200 Latency:290.600597ms Bytes-In:0 Bytes-Out:1959

1. List Nodes/Deployments/Pods
2. Show Node/Pod level metrics

For each connected endpoint, dispatch an action that will invoke an API call for the endpoint that serves as a health check - if it fails, the global error handler should pick this up and the endpoints view should then show the red error row beneath the endpoint that has an issue.

• apply time frame selector to summaries
• reduce wording of summary titles
• title sentence case rather that captialised