Dashboard: Introduce settings page

[maciaszczykm]

It is a feature, that is blocking few other features. People using Dashboard would like to change things like language, theme etc. directly from the app.

• [x] introduce settings page
• [ ] add language picker where user is able to switch between browser's locale and the one chosen by him (mentioned in #2240)
• [ ] add color/theme picker where user is able to pick primary theme's color (mentioned in #1657)
• [x] add items per page switch (mentioned in #1703)
• [x] add cluster name to settings, that will be part of window title (mentioned in #2239)
• [x] add logs refresh time interval input field (mentioned in #2496)

[cheld]

Another option is to use config map for settings page

[cheld]

Another feature for settings page: Cluster name
https://github.com/kubernetes/dashboard/issues/2239

[maciaszczykm]

@cheld Config map will be used for global settings and cookies for local ones.

[maciaszczykm]

I am starting to work on local ones.

[maciaszczykm]

@cheld Regarding our talk today... The more I think about it the more I am concerned about putting all switches across the app instead of creating local settings page. My major concern is where we will put language picker if not on settings page. Same question for almost all resources. I will check if I will be able to retreive any data about current user to base all settings on config map.

[cheld]

You could put it next in a pull down menu of the user. In general it is just my UX feeling. We could also talk about with dan or raul or some more people to get better feeling what makes sense

[maciaszczykm]

Sounds nice, I have similar thinking about it. I will check if we can get username/id/whatever what is unique to store all config in config map as I see it as the best solution at the moment.

[maciaszczykm]

After some checking, I think we should be able to implement settings based on config map stored in the cluster. Such a map would store settings of all users that modified at least one setting (to make it more efficient). We would use user IDs as keys, and settings objects as values.

The main concern at the moment is picking right user ID/hash. As far as I know, client-go does not expose any API to get any information about the current user, that will be useful for us (@caesarxuchao, could you confirm?). In that case, we would have to generate user ID/hash on our own. We can do it based on service account name/token/username/certificate I suppose.

@liggitt Should information about service account name/token/username/certificate that is used be enough for it? Do you know any API that might be helpful?

[maciaszczykm]

Being able to get https://github.com/kubernetes/kubernetes/blob/61e7d1ebf1e19023bc48cc573fbbbe20f0f01f0d/staging/src/k8s.io/apiserver/pkg/authentication/user/user.go#L20 information through API would be very useful here I think.

[ofpiyush]

Before releasing the detailed user-scoped settings out, If there is some way to have even global color scheme + cluster name, it would be extremely useful for people handling multiple clusters.

[maciaszczykm]

@ofpiyush The app itself is stateless. It means that we have two major options at the moment - config map or cookies. Cookies are browser-dependent and it makes them a bad option for mentioned settings. The only good solution is to store this data inside config map, at least for cluster name.

[ofpiyush]

@maciaszczykm I agree. I saw conversation on making the configmap key = user hash of some kind. That implies trying to scope configuration per user.

ClusterName and color for example can remain global and would not be blocked on getting a reliable hash out of the authentication package.

I strongly urge you guys to implement the global ones first so that we can start using these much needed features.

Sorry for adding more messages to read through.

[maciaszczykm]

@ofpiyush Sure, no problem. I understand. We are a bit short of developers currently, but you can expect it in next release.

Regarding making it global for all users - it makes sense with cluster name, but not for color schemes in my opinion.

@cheld Can you share opinion?

[cheld]

In case of settings it makes sense to think about complex use cases conceptually, but start implementing a MVP

In terms of global or user specific setting (like color), we could start with global settings and later on allow users to overwrite the global settings with personal ones

I believe the global settings (backed on config map) are more needed and have more impact.

In terms of storage to config map a few things come to my mind that might be needed to be considered

• concurrent writes (are updates atomic?)
• compatibility (what can be changed in the schema after first release?)
• version migrations (we need a version number at least)
• format (json, key-value, ...?)
• security (in case of user storage)