Extend the defaults accepted via configuration

[benedikt-haug]

What this PR does / why we need it:
This PR is part of the Hackaton.
This PR extend the defaults gardener dashboard accepts via configuration.
Additionally, it moves the default declaration to the config store so they are declared in the same spot.
Lastly, it also adds the example folder describing the new additions made possible by the gardener-dashboard-frontend configmap.

Which issue(s) this PR fixes:

Special notes for your reviewer:
/cc @marc1404 @klocke-io

Release note:

Extend the defaults gardener dashboard accepts via configuration

[gardener-robot-ci-2]

Thank you @benedikt-haug for your contribution. Before I can start building your PR, a member of the organization must set the required label(s) {'reviewed/ok-to-test'}. Once started, you can check the build status in the PR checks section below.

[gardener-robot]

@benedikt-haug Thank you for your contribution.

[klocke-io]

/ok-to-test

[grolu]

Nice!
Please also have a look at this PR: #2467
Especially the defaultInfrastructures configuration may cause conflicts.

[grolu]

Maybe it would be better to group the default options under a key in the config, e.g., shootDefaults. This way, we can ensure the config remains clear and all shoot default settings are grouped together. These settings are also likely to grow, so this approach gives us better control.

Additionally, these values need to be added to the Helm charts. Right now, the Helm charts are the only documentation for the dashboard configuration. We should consider introducing a dedicated documentation page for the configuration — but that’s a separate task and not related to this PR.

[benedikt-haug]

Nice! Please also have a look at this PR: #2467 Especially the defaultInfrastructures configuration may cause conflicts.

Sure <3
On quick glance it looks like all it would take to allow user overrides for your new knownInfraVendors array would be to move the defaulting function to store/config.js, just like this PR does for all the other defaults.

Maybe it would be better to group the default options under a key in the config, e.g., shootDefaults. This way, we can ensure the config remains clear and all shoot default settings are grouped together. These settings are also likely to grow, so this approach gives us better control.

Seems reasonable :) Incorporated that feedback. Also moved the "old" variables there, while including a fallback for the users of the old naming scheme so things don't suddenly break.

Additionally, these values need to be added to the Helm charts. Right now, the Helm charts are the only documentation for the dashboard configuration. We should consider introducing a dedicated documentation page for the configuration — but that’s a separate task and not related to this PR.

Added an example like the other repos have it. Also tried to extend the helm charts to feature the new variable. Do you know how to test the charts locally, helm template . ain't working for me?

[grolu]

Do you know how to test the charts locally, helm template . ain't working for me?

We implemented tests for the help charts. You can adapt them and run them with yarn test in the charts directory

[grolu]

we should introduce a shootDefaults computed that defaults to {} to reduce optional chaining.

[gardener-robot]

@holgerkoser, @klocke-io You have pull request review open invite, please check