refactor(kubernetes-dashboard): move override to separate values.yaml file

[muse-sisay]

Description

• store override in a separate values.yaml file
• upgrade chart to version 7.9.0
• append cluster name to dashboard endpoint

Related Issue(s)

• Resources in components directory were installed in the local cluster. As a result ingress resource wasn't available for downstream clusters.
• Conflicting DNS names for multiple instance of Kubernetes dashboard

How to test

Follow steps in Contributing.md to deploy the app.

[CristhianF7]

ArgoCD will complain because of having the same name for resources and since apps can be installed in different clusters we will have the same problem

[CristhianF7]

Suggested change

	name: dashboard-user
	name: <CLUSTER_NAME>-dashboard-user

[CristhianF7]

Suggested change

	name: dashboard-user
	name: <CLUSTER_NAME>-dashboard-user

[muse-sisay]

Hey @CristhianF7

Indeed, ArgoCD raises an error if two Applications are managing the same resource. (i.e the resource has the same name, destination cluster and type ). In this PR though, the service-account and role binding are created in downstream cluster. Even though in multiple installation of the app the resource have the same name they are not the same resource.

There is going to be a problem if a user installs two copies of the app in the same downstream cluster. Luckily that is not a feature we support and don't have to worry about, for now.

bonus point : Because the resources are name the same across different downstream accounts, if we ever write script/automation or ask user to ran some sort of command (eg. kubectl -n kubernetes-dashboard create token dashboard-user), they don't have to modify the resource name to match the cluster they are running against.

Muse

[CristhianF7]

Hey @CristhianF7

Indeed, ArgoCD raises an error if two Applications are managing the same resource. (i.e the resource has the same name, destination cluster and type ). In this PR though, the service-account and role binding are created in downstream cluster. Even though in multiple installation of the app the resource have the same name they are not the same resource.

There is going to be a problem if a user installs two copies of the app in the same downstream cluster. Luckily that is not a feature we support and don't have to worry about, for now.

bonus point : Because the resources are name the same across different downstream accounts, if we ever write script/automation or ask user to ran some sort of command (eg. kubectl -n kubernetes-dashboard create token dashboard-user), they don't have to modify the resource name to match the cluster they are running against.

Muse

Hey @muse-sisay

Thanks for clarifying. I just wanted to double check because we faced this error several times