dashboard

dashboard copied to clipboard

What type of PR is this? /kind feature

What this PR does / why we need it:

1. Construct the main page layout with a topbar and sidebar.
2. Creating page routing.
3. Create Override Policy, Resource Binding and Works pages. Sub-pages includes: Override Policy, Cluster Override Policy, Resource Binding, Cluster Resource Binding, and Works.
4. Create a data grid component for displaying summary of response from backend endpoint API. Create a Tree view to view details of the responses.
5. Create Frontend API that dynamically fetch data through backend endpoints of Karmada-api-server.

How to run this PR locally?

1. Pull the PR locally. Make sure you have latest Node.js.
2. Follow the instructions in README.me.

Special notes for your reviewer: TEST mode: a dev feature for easier debugging program locally.

This mode allows user to generate some mock data based on the go-server API spec file, karmada/master/api/openapi-spec/swagger.json. The test mode bypass the authentication token check and allow you to go to preview the pages populated with mock data.

To enable testing mode, go to root folder, find .env file, and change "REACT_APP_STAGE=DEV" to "REACT_APP_STAGE=TEST". Use uppercase! To exist TEST mode, just change that field back to "DEV".

The testing script generates five sets of response data, each for the following API path: /apis/policy.karmada.io/v1alpha1/overridepolicies /apis/policy.karmada.io/v1alpha1/clusteroverridepolicies /apis/work.karmada.io/v1alpha2/resourcebindings /apis/work.karmada.io/v1alpha2/clusterresourcebindings /apis/work.karmada.io/v1alpha1/works

, in accordance with pages: Override Policy Cluster Override Policy Resource Binding Cluster Resource Binding Works.

---

demo: https://raw.githubusercontent.com/AdaTempImg/temp1/main/LFX%20demo.gif

Signed-off-by: Jun Xiang [email protected]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: To complete the pull request process, please assign rainbowmango after the PR has been reviewed. You can assign the PR to them by writing /assign @rainbowmango in a comment when ready.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment Approvers can cancel approval by writing /approve cancel in a comment

@RainbowMango @chinmaym07 Please take a look.

demo: https://github.com/AdaTempImg/temp1/blob/main/demo.gif Example mock data of path, /apis/policy.karmada.io/v1alpha1/overridepolicies: https://github.com/AdaTempImg/temp1/blob/main/Mock%20Data.json

Does this demo base on static data?

@RainbowMango No, each time you go to the page, new data is generated randomly. Do you want static data? Or do you have a specific set of data for testing?

No, each time you go to the page, new data is generated randomly. Do you want static data?

I mean, we should get the data from karmada-apiserver dynamically. Just like what I asked on https://github.com/karmada-io/dashboard/pull/27#issuecomment-1229614816.

@RainbowMango I fixed that login issue and successfully verified the part to dynamically fetch data from the backend endpoints, aka from the Karmada-apiserver. Please see the new demo.

demo: https://raw.githubusercontent.com/AdaTempImg/temp1/main/LFX%20demo.gif

Here is the example .yaml file I use to define the Override Policy in my Karmada during demo:

apiVersion: policy.karmada.io/v1alpha1
kind: OverridePolicy
metadata:
  name: example-override
  namespace: default
spec:
  resourceSelectors:
  - apiVersion: helm.toolkit.fluxcd.io/v2beta1
    kind: HelmRelease
    name: podinfo
  overrideRules:
  - targetCluster:
      clusterNames:
        - member1
    overriders:
      plaintext:
        - path: "/spec/values"
          operator: add
          value:
            replicaCount: 2 

and the resource template .yaml:

apiVersion: source.toolkit.fluxcd.io/v1beta2
kind: HelmRepository
metadata:
  name: podinfo
spec:
  interval: 1m
  url: https://stefanprodan.github.io/podinfo  
---
apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
  name: podinfo
spec:
  interval: 5m
  chart:
    spec:
      chart: podinfo
      version: 5.0.3
      sourceRef:
        kind: HelmRepository
        name: podinfo

@RainbowMango @chinmaym07 Please take a look.

@chinmaym07 Yes, having tree view at the bottom of data grid is not a good from UI/UX perspective. I suggest to make it as popover layer when you click on an action button in any of the row. The tree view is great for CRUD. We got read already. Write and delete can be done with the text window next to the tree view with slight modification. For creating a new override policy, let's just import a JSON/YAML and forward it in a POST request.

Other features can include search bar and filtering bar. They are already built-in in MUI Datagrid, I just need to correctly configure them. Also I can write some shell script to automate the deployment process.

/close as lack of activities.

@RainbowMango: Closed this PR.

In response to this:

/close as lack of activities.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.