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:

**New `shootDefaults` configuration introduced:** A new top-level configuration property, `shootDefaults`, has been added. Existing shoot default settings have been moved under this new namespace:

- `controlPlaneHighAvailabilityHelp` → `shootDefaults.controlPlaneHighAvailabilityHelp`
- `defaultHibernationSchedule` → `shootDefaults.hibernationSchedule`
- `defaultNodesCIDR` → `shootDefaults.nodesCIDR`

The previous configuration locations are now deprecated. Please update your deployments to use the new `shootDefaults` configuration paths.

Improved shoot creation defaults: The Gardener Dashboard now allows predefined default values when creating new shoot resources

[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

[gardener-robot]

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

[benedikt-haug]

Hey @grolu,
thanks for having a look :)

I think I've successfully pulled off the rebase :D
Added the configStore to the cloudProfile.

You are correct about my changes being a breaking change. Is announcing this something I'd do in this merge request or something that is written somewhere else?

I personally don't need to change the infrastructure list. I just wanted to move all hardcoded defaults to configstore. I thought that maybe it would be fun to be able to change the sorting to prioritize specific infrastructures or something.

[grolu]

You are correct about my changes being a breaking change. Is announcing this something I'd do in this merge request or something that is written somewhere else?

It is sufficient to mention in the PR description with breaking operator

I personally don't need to change the infrastructure list. I just wanted to move all hardcoded defaults to configstore. I thought that maybe it would be fun to be able to change the sorting to prioritize specific infrastructures or something.

Right, exactly this can now be achieved using weights in the vendor configuration. So I think we can drop the infra defaults in this PR

[benedikt-haug]

@grolu
I dropped the whole infrastructure changes as discussed.
Tried to write a good breaking change, please have a look :)

[grolu]

Okay this looks good. I also like that you added configuration examples to the values.yaml.
I polished your release notes to provide some more details.
I will now do some final testing.

[grolu]

Hi @benedikt-haug
I need to do some further checks concerning edge cases, like for example we have some defaulting depending on the selected cloud profile which might limit available purposes. I need to verify if this PR might break things like that. Pease give me some time. I will not be available next week so expect my feedback after that.

[gardener-prow]

PR needs rebase.

Details

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.

[grolu]

Hi @benedikt-haug

I tested your PR. Unfortunately, multiple things are not working as expected:

• Control Plane High Availability: Always (half) selected, regardless of config
  • Control plane failure tolerance type zone configured
  • Even though CP high availability checkbox not ticked
  • Enabling / Disabling not working
• Workerless Cluster
  • If enabled by default, no Worker Group is added when disabling it
• networkingType
  • networkingTypesList not used in defaulting / component (probably bug with us)
  • maybe makes sense to rename to sortedNetworkingTypes
• All worker defaults not working
  • All default computeds currently unused
• LoadBalancer / Floating Pool not working
  • computeds not used
  • You need to pay attention to the wildcards when defauling

Also, it probably makes sense to put a hint into values.yaml stating that it is not recommended to remove the built-in default purposes evaulation, development, production as there are hardcoded defaulting mechanism based on those. Also, some help texts do not make any sense without them.

Moreover, your PR needs to be rebased with master.

[gardener-ci-robot]

The Gardener project currently lacks enough active contributors to adequately respond to all PRs.
This bot triages PRs according to the following rules:

• After 30d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 14d of inactivity since lifecycle/rotten was applied, the PR is closed

You can:

• Mark this PR as active with /lifecycle active
• Mark this PR as fresh with /remove-lifecycle stale
• Mark this PR as rotten with /lifecycle rotten
• Close this PR with /close

/lifecycle stale

[grolu]

Hi @benedikt-haug can you check and fix the issues mentioned above

[benedikt-haug]

Sadly I'm currently overloaded :(
I'll try to get back to this once I've got a bit more free time.