kyma-project / busola Goto Github PK

As Sebastian and Mathew I would like to be able to be able to see Storage Classes in the Busola UI.
Acceptance Criteria

• Follow Project DOD
• We introduce a Storage Menu item
• A List View is available
• A Detail View is available
• #810
• Create/Edit view is available - with yaml editor only
• Tests are present testing the functionality

Tasks

• Add Tasks

Description
I would like to use my default kubeconfig with busola running locally (docker mode).

Reasons
It is natural for developers that K8s tools use the current kubeconfig automatically.
I don't want to upload anything or have additional tools to construct some query parameters. It should be standard command to mount kubeconfig file as a volume in the docker and use all the contexts from it automatically.

Description

We should unify the way we present our dropdowns

Reasons

The UI should be consistent and predictable. The user wants to use the same patterns all over the app

Attachments

Description

Similar to google cloud shell, we can provide a shell that the user can launch and run various commands to try out samples.

Motivation

Often, developers have challenges installing required tooling such as docker, kubectl, helm, others...
There could be constraints from their IT department, company policies.

Another set of users exploring cloud-native technologies such as Kyma is middle to upper management, such as Product Managers, CTOs. They would not bother spending time to set up the prerequisite tooling.

For both such cases, having an option to activate a shell and just use it would be a huge benefit.

Reference to gardener ops-toolbelt image: https://github.com/gardener/ops-toolbelt/tree/master

Description

Create API Rule from Configuration tab in function details.

Reasons

We should have automated tests and don't test manually.

Description

We don't need to use OIDC for this - we can just create service account with a specific set of permissions, download kubeconfig for it, and then switch to cluster using that kubeconfig.
https://docs.oracle.com/en-us/iaas/Content/ContEng/Tasks/contengaddingserviceaccttoken.htm

As Sebastian and Mathew I would like to be able to be able to see Persistent Volumes Claims in the Busola UI.
Acceptance Criteria

• Follow Project DOD
• We introduce a Storage Menu item
• A List View is available
• A Detail View is available
• Create/Edit view is available - with yaml editor only
• Tests are present testing the functionality

Tasks

• Add Tasks

Description

Currently, the UI spells the CR's name API Rule, but Kyma documentation uses the APIRule spelling pattern that's compliant with the spelling of other Custom Resources.
This needs to be unified.
It was decided to change API Rule to APIRule in the UI.
Following a discussion on this issue, It was decided to use natural language for Custom Resource names in the Busola UI.

Area

• Busola/Kyma Dashboard
• Documentation

Reasons

Documentation describes steps in Busola and the naming is not consistent.
The naming in the UI and the documentation must be consistent.

Assignees

@kyma-project/technical-writers

Attachments

Related issue

• kyma-project/kyma#12473
• kyma-project/community#600

Description

Migrate DaemonSets to generic create view. We should use the patterns as the rest of Create Resource.

Reasons

To be consistent with the rest of the application.

Description
Improve the UX of the sidebar overlay (the edit panel)

Reasons

We need a consistent UI so that the user

Acceptance Criteria

• Adjust the styling as presented in the image
• Introduce a Download YAML
• Introduce a Search/Filter field
• Maximize to full screen and repositioning it's not part of this task
• The Overlay can be resized

Attachments

As Sebastian and Mathew I would like to be able to be able to see Persistent Volumes in the Busola UI.
Acceptance Criteria

• Follow Project DOD
• We introduce a Storage Menu item
• A List View is available
• A Detail View is available
• Create/Edit view is available - with yaml editor only
• Tests are present testing the functionality

Tasks

• Add Tasks

Description

As user I would like to be able to see the pods that are attached to a function so that I can be able to click on them and see the logs.

Reasons

We would like to make it easier to access the pods and also the logs for those pods.

Tasks

• Move Env Variables to the config tab
• Add the pod listing general view underneath the code editor
• Improve the api calls so that we only refresh the resources that are needed for that tab view

As Sebastian and Mathew I would like to be able to see the list and the details of the Ingress that are in My Cluster, and also be able to create and modify existing ones

Acceptance Criteria

• Follow Project DOD
• This is part of Discovery and Network
• Listing View is Created. Use the fields State | Name | Target | Host| Path | Age - as a starting point
• Detail View is Create
• Create Window is available - with yaml editor only
• We support only Latest version of Ingress. We will cover the edge-cases in: #706
• Tests are present testing the functionality

Tasks

• Add Tasks

As a Busola Administrator, I would like to be able to configure certain parts of Busola at runtime. I would like to enable features and disable features without needing a new build.

Acceptance Criteria

• Introduce a config that can be changed at Runtime on the cluster that runs busola. config map that would be loaded byt busola
• This config be used to toggle on and off features of the apps and also pass various general configurations. All configurations will have a sensitive default. The order of overwriting is:

1. Defaults
2. Config Map
3. Enkode parameters

Description

As Matthew or Sebastian I would like to have a guided approach for my first time Busola Experience.

Attachments

Acceptance criteria

• Use an empty state ( if no cluster is present ) icon from designing-for-empty-states
• We use the Monaco editor with yaml formating for the kubeconfig section
• We have a 2 step wizard
• We need to validate the yaml in the second step, and reject yamls that don't have a CA
• Check the complete mockup in the UX folder

Description
When we maintain an environment variable in the function from the secret, there is a dropdown to select a secret.
Currently, it is just a dropdown. And we need to scroll a long list to find the required secret. It would be great if it can be a searchable dropdown.

Reasons

If the namespace has many secrets (for different reasons), it's difficult to find the right one.

Attachments

Description
Check Pod logs in in-cluster eventing flow is missing. Logs don't load in browser launched by Cypress probably due to cypress-io/cypress#1185 issue.

It didn't help too: cypress-io/cypress#15259 (comment)

Maybe we could check logs in Grafana??

Description
Function ENVs injected via secrets or configmaps are not visible in the busola UI

Expected result

User should see envs that are used from secrets or config maps

Actual result

Function UI in busola supports only envs with value. Envs with valueFrom are skipped

  env:
  - name: FOO
    valueFrom:
      secretKeyRef:
        key: foo
        name: test-secret
  - name: ABC
    valueFrom:
      configMapKeyRef:
        key: abc
        name: test-config
  - name: HAKUNA
    value: MATATA

Steps to reproduce

1. Have a kyma cluster running and accesible via CLI and Busola UI

2. Prepare test config map and test secret in the default namespace

kubectl create configmap test-config --from-literal abc="xyz" -n default
kubectl create secret generic -n default --from-literal foo="bar" test-secret

3. Initialise a simple function via kyma CLI (make sure you use latest version)

kyma init function --name test --namespace default --runtime nodejs14

4. Modify config.yaml

name: test
namespace: default
runtime: nodejs14
source:
  sourceType: inline
env:
  - name: FOO
    valueFrom:
      secretKeyRef:
        name: test-secret
        key: foo
  - name: ABC
    valueFrom:
      configMapKeyRef:
        name: test-config
        key: abc
  - name: HAKUNA
    value: MATATA

5. Modify handler.js

module.exports = {
    main: function (event, context) {
        return process.env["FOO"] + process.env["ABC"];
    }
}

6. Apply function

kyma apply function 

7. Navigate to busola UI and show the function

Observe that ENVs injected from config map and secret are not shown

8. (Optional) Expose the function to see that the env values are injected (they are part of the returned value )

Hints

This works on console.
It was introduced probably after creating busola repository.
Please have a look at this PR which introduced it to console (Maybe it is easy to port the changes to busola)

Description

Automate Cypress tests for BTP Service Instance feature

Reasons

We should have automated tests and don't test manually.

Description

When you create a new secret with a preset you will start with a list of keys. But if you read the value for the key from the file, the key name is replaced with a file name.

Expected result
The key name stays as it was defined in the preset

Actual result

Key name is equal to file name

Steps to reproduce

Create new secret with preset GoogleCloud DNS, switch to Advanced mode, go to 'serviceaccount.json' key and read the value from file. When the file is loaded the file name will replace the key name.

SPIKE: #772

Description

As Matthew or Sebastian I would like to have autocompletion when I edit a K8s YAML file. I would also like to have validation before sending it to the server, to have the confidence that my changes are without errors

Reasons

Having autocompletion and validation helps and assist the user and avoids unnecessary errors. This also helps the user to avoid searching in the documentation for

Attachments

• see language-server-protocol
• see gardener implementation of their YAML editor openapi
• example implementation
• posible library

Acceptance criteria

• Autocompletion is triggered in edit mode
• Validation is happening while typing. If validation fails, you cannot save
• Contextual help is displayed while hovering yaml elements ( see Gardener )
• This task targets native k8s resources only
• It should be possible CR, by using the CRD Schema. Implementation is not part of this task, only if easy low hanging fruit
• The editor will not replace the current editor and will be toggled via feature flag
• Mirroring the current Monaco editor functionality ( search, toggle visibility, download ) is not part of this task

Description

We need to be consistent with the rest of the Create Resource Views and to use the same fields and patterns so that our users don't feel confused.

Reasons

We want our UI to guide the user and make him feel confident when he creates a new DNS Entry

Acceptance Criteria

• Arrange all the forms as we have in the Create Gateway View
• Introduce Tooltips to all elements explaining what are those fields about. The initial explanations come from the CRD Schema or Official Documentation
• Refactor the Secret Selection so that is a 2 step process. Select Namespace ( with option to search ) and Select Secret ( with option to search ).Make sure we don't show system namespaces if Show hidden Namespaces is toggles off
• All the Domains fields that allows more than one domain should use the new ui ( this is targets )
• simplify the basic view ( add DnsName and Targets - one instance - advanced will have more than one )
• Check if we are on gardener (namespaces/kube-system/configmaps/details/shoot-info) and add annotation dns.gardener.cloud/class: garden
• Text Name should use the same UI Targets ( multi items )
• Targets is an advanced one - where you can toggle cname and loadbalancer. For loadBallancer we do a 2 step selection wehre we display all SVC of Type loadbalancer
• DnsName should be autosugested from the DNSProvider included domains

Description

Introduce selected state for the item that is being edited.

Reasons

Improves orientation and avoids editing the wrong item

Acceptance Criteria

• The edited item is selected while edit panel is open
• We can deep link to the edit mode

Attachments

Have a nightly build pipeline for Busola.

As Sebastian and Mathew I would like to be able to see the list and the details of the VirtualServices that are in My Cluster, and also be able to create and modify existing ones

Acceptance Criteria

• Follow Project DOD
• This is part of Istio Navigation Grouping (Gateways are also part of the same group )
• Listing View is Created. Use the fields State | Name | Gateways | Hosts | Age - as a starting point
• API Rules are deep linked with corresponding Virtual Services
• Detail View is Create
• Create Window is available - with yaml editor only
• Tests are present testing the functionality

Tasks

• Add Tasks

Description

Automate Cypress tests for DNS Provider feature:

• list view
• detail view
• add view

Reasons

We should have automated tests and don't test manually.

Description

When a kubeconfig without a valid callback URL (for auth provider) is uploaded as the only one, Busola will repeatedly try to connect into the cluster, resulting in a loop that makes it unusable.

Expected result

There should be a possibility to not connect to a specific cluster by default.

Actual result

When accessing Busola it connects to the first available cluster by default. If no callback URL is provided in the kubeconfig it will repeatedly fail.

It automatically redirects to the auth provider and fails:

Steps to reproduce

1. Upload kubeconfig with auth configured and no callback URL
2. Try to access Busola

Troubleshooting

The only solution is to wipe the local cache or use the incognito mode.

Description

We need to be consistent with the rest of the Create Resource Views and to use the same fields and patterns so that our users don't feel confused.

Reasons

We want our UI to guide the user and make him feel confident when he creates a new Certificate

Acceptance Criteria

• Arrange all the forms as we have in the Create Gateway View
• Introduce Tooltips to all elements explaining what are those fields about. The initial explanations come from the CRD Schema or Official Documentation
• Refactor the Secret Selection so that is a 2 step process. Select Namespace ( with option to search ) and Select Secret ( with option to search ).Make sure we don't show system namespaces if Show hidden Namespaces is toggles off
• All the Domains fields that allows more than one domain should use the new ui
• simplify the basic view (remove dns name and and issuer CSR Not checked by default

Description

We need to be consistent with the rest of the Create Resource Views and to use the same fields and patterns so that our users don't feel confused.

Reasons

We want ou UI to support the user and make him feel confident when he creates a new Issuer

Acceptance Criteria

• Arrange all the forms as we have in the Create Gateway View
• Introduce Tooltips to all elements explaining what are those fields about. The initial explinations come from the CRD Schema or Official Documentation
• Basic Views has all the necessary fields to create a valid issuer ( add Includes Domains ). All collapsible fields are open
• Introduce Templates for Lets Encrypt Production, and Staging to support the user with some valuable defaults
• Refactor the Secret Selection so that is a 2 step proces. Select Namespace ( with option to search ) and Select Secret ( with option to search )
• Don't show system namespaces if Show hidden Namespaces is toggles off
• All the Domains fields ( Include and Exclude ) should use the new Add item one by one component that Create Gateway View uses

Description

Enhance api rule view in a way that it allows user to select gateway. User gets to select gateway from all gateways defined in his namespace + gateways from kyma-system namespace (consider putting note / info / ? to explain source of gateways combo box). Once user selects gateway hostname field is populated depending on hosts entries in selected gateway (consider changing field name to fully qualified domain name). Please note that there can be many hosts defined in gateway either they can be "exact match" or wildcard. In case of wildcard use have possibility to add hostname but if it's "exact match" user shouldn't be allowed to type in anything in front.

AC:

• user can select gateway for api rule
• hostname is pre-populated from previously selected gateway's hosts

Reasons

Gives user more flexibility to expose his workload under his domain.

Attachments

https://istio.io/latest/docs/reference/config/networking/gateway/
kyma-project/kyma#11828

Description

Local busola shows extremely high cpu utilisation

Expected result

CLI and UI should show the same cpu utilisation

Actual result

Value form CLI

kubectl top nodes
NAME                CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
k3d-kyma-agent-0    323m         8%     2062Mi          25%
k3d-kyma-server-0   684m         17%    3691Mi          46%

Value seen in busola
( ~10100% )

Steps to reproduce
Follow instructions from quick install guide:

1. Install local kyma instance

kyma provision k3d
kyma alpha deploy

2. Start local busola
3. Go to cluster overview page

Description

Test adding kk with multiple contexts

Description

Reasons

Attachments

Description

Switch between clusters, add them, remove them, add invalid, inaccessible

Description

Busola needs to have translation system integrated and aligned with SAP Product Standards.

Acceptance Criterias

• Translation is part of the codebase
• Translation files are in friendly format that can be edited by translators and technical writers

Description

We need to use just one way of displaying tooltips. See recommended option in screenshots.

Reasons

UX needs to be consistent so that users does not get confused

.Acceptance Criteria

• All input fields are checked, and we use the recommended ui display delay 1.5-2sec with the help insights
• We remove all the info icons and ? icons
• If the help content is too long for a tooltip or with deep expert information we need to identify and capture those sections and work with a TW to reduce the size

Attachments

Description

As a user I would like to be able to see and edit the available CRD and CR in my cluster.

Reasons

Tasks

• CRD are visible at Cluster Overview -> Admin
• CR are visible at the namespace level Configuration -> Custom Resources
• We use the generic list and detail view, and you can edit them via the generic yaml editor

Description

Migrate Services to create generic modal. We should use the patterns as the rest of Create Resource.

Reasons

To be consistent with the rest of the app.

Description

In resources directory, we keep the configuration for web and backend deployments. They can use either PR tags (e.g. PR-123) or short commit hash tags (e.g. 3ee9d13a). After an ordinary PR is merged, we would like to have the images automatically bumped from PR tags to the commit hash of previously merged PR (unless it's a bump PR).

Description

Automate Cypress tests for DNS Entry feature

• list view
• detail view
• add view

Reasons

We should have automated tests and don't test manually.

Description

Extend our smoke Cypress tests for missing views.

Reasons

We have a lot of views which are not covered by our Smoke tests.

Description

Migrate StatefulSets to generic create modal. We should use the patterns as the rest of Create Resource.

Reasons

To be consistent with rest of the application.

Log view should default to newest first and indicate that it will auto refresh.

Summary

Perform Get Started guide for Busola on Firefox and Safari.

Prerequisites

• access to Busola

Environment
Kyma runtime

Test Steps
Perform Get Started guide in Busola.

Automation

• Cypress doesn't work well with iframes on Firefox. Luigi supports webcomponents instead of iframes (possible solution).
• Safari is not supported by Cypress.

Description

Automate Cypress tests for BTP Service Binding feature

• list view
• detail view
  -add view

Reasons

We should have automated tests and don't test manually.

Description

Implement set of forms to add / edit gardener dns and cert management CR.

User should be able to create DNSProvider:

cat << EOF | kubectl apply -f -
apiVersion: dns.gardener.cloud/v1alpha1
kind: DNSProvider
metadata:
  name: aws
  namespace: default
spec:
  type: aws-route53
  secretRef:
    name: aws-credentials
  domains:
    include:
    # this must be replaced with a (sub)domain of the hosted zone
    - my.own.domain.com
EOF

• type - predefined list of supported providers,
• reference to secret with credentials (aws-credentials) - secret should be created before user tries to create DNSProvider. This field can be already populated from secrets on a cluster.
• domains - list of domains, user needs to provide this information, cannot be calculated

Next step would be to create DNSEntry:

cat << EOF | kubectl apply -f -
apiVersion: dns.gardener.cloud/v1alpha1
kind: DNSEntry
metadata:
  name: mydnsentry
  namespace: default
spec:
  dnsName: "myentry.my-own-domain.com"
  ttl: 600
  targets:
  - 1.2.3.4
EOF

• dnsName - user provided, partially can be calculated from DNSProvider domain (in first iteration can be simply provided by an user)
• ttl - user provided, values can be sugested
• targets - list of IP addresses, can be selected from all service of type LoadBalancer (in case of kyma it's IP address of istio ingress gateway but i would leave user flexibility to choose from svc type LB)

Creation of Issuer:

apiVersion: cert.gardener.cloud/v1alpha1
kind: Issuer
metadata:
  name: issuer-staging
  namespace: default
spec:
  acme:
    server: https://acme-staging-v02.api.letsencrypt.org/directory
    email: [email protected]
    autoRegistration: true
    # with 'autoRegistration: true' a new account will be created if the secretRef is not existing
    privateKeySecretRef:
      name: issuer-staging-secret
      namespace: default

• server - user provided (i'm not sure if we want to suggest anything here)
• autoRegistration - checkbox. depending of whether it's checked or not we might handle secret reference in different way
• secret reference - in case user checked autoRegistration then he can provide name and namespace (we can suggest some default value e.g. issuer-name-secret). if user did not check autoRegistration then we can list existing secrets for user to choose from

Certificate:

apiVersion: cert.gardener.cloud/v1alpha1
kind: Certificate
metadata:
  name: cert-simple
  namespace: default
spec:
  commonName: cert1.mydomain.com
  dnsNames:
  - cert1-foo.mydomain.com
  - cert1-bar.mydomain.com
  # if issuer is not specified, the default issuer is used
  issuerRef:
    name: issuer-staging

• commonName - partially can be calculated from existing domains
• dnsNames - list, partially can be calculated
• issuer - reference to existing issues

Reasons

Simplify steps which customer needs to execute to expose his workload.

Attachments

part of: kyma-project/kyma#11839
depends on: kyma-project/kyma#11828

Description

As Matthew or Sebastian I would like to have have the links to the observability stack inside Busola

Reasons

Observability stack is a common stack that is needed for a Dashboard, we need to have a flexible way to be able to identify if what observability applications are running on the cluster, and what are their urls.

Acceptance criteria

• The selection path and the label of the tool are part of the Busola Config, and they have sensitive defaults, can be overwritten by enkode params and Busola Cluster Config
• We use the Kyma defaults, that are using VirtualServices(specs/host) to identify if the tools are available and what urls they have
• If multiple hosts are present, we pick the first one in the list
• If No tools is available, the whole observability section is hidden
• We are going to add the Observability section above the External Nodes section
• We target for beginning Grafana, Tracing and Kiali

Description

As Sebastian I would like to be able to toggle Busola features on and off, and also be able to do small adjustments per feature.

Reasons

Being able to have feature toggle enable us:

• to have long standing developments of features and still do continuous delivery,
• be able to do AB testing of feature, and Canary Rollouts
• quickly rollback broken features

Acceptance criteria

• Each feature will have a uniqID, and a config payload
• We will release a JSON schema for the config, and we will validate every step we import the Busola configuration ( enkode params, Cluster ConfigMap )

Suggested structure

var config = {
  "kubeconfig": {
  //  this follows the kubeconfig structure
  },
  "config": {
    "navigation": {
      "componentsNodes": [
        // id of components that would be added to navigation
      ],
      "externalNodes": [ // this are mainly links
        {
          "id":"this_will_be_an_unique_id",
          "category": "Learn more",
          "icon": "course-book",
          "children": [
            {
              "id":"this_will_be_an_unique_id",
              "label": "Kyma Documentation",
              "link": "https://kyma-project.io/docs/"
            }
          ]
        }
      ],
      "disabledNodes": [
        // id of nodes will not be displayed
      ],
    },
    "hiddenNamespaces": [
    ],
    "components": {
      "SERVICE_CATALOG": { //this is a unique ID that identifies the component /feature
        "id":"SERVICE_CATALOG",
        "enabled": true,
        "config": {
          // here would be component specific configurations
        }

      }
    }
  }
}

Description
We need to mark all the mandatory in our dialogs.

Reasons

The user needs to clearly understands what forms he needs to fill.

Acceptance Criterias

• Add mandatory field asterisk​

• Insure actions consistency: ​

  • cancel button should be on all dialog ovelays​
  • actions order is not compilant to SAP UX Guidelines (lead action should always be 1rst in a row and emphasized)​

• Double check the dialog titles are consistant with the button lables, which trigger the dialog ​

Within the Overview pane of a namespace the option to "Deploy new workload" only allows you to "Create Function" or "Create Deployment". There should be an option to "Upload YAML" matching what is currently in Kyma 1.x