Feature hide elements of NewShoot dialogue

[benedikt-haug]

What this PR does / why we need it:
This PR is part of the Hackaton.
This PR allows the operator to hide elements of the NewShoot dialogue.

Without configuring anything, nothing should change. The end-result might be:

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

Release note:

Allow hiding parts of the newShoot dialogue

[ghost]

@benedikt-haug Thank you for your contribution.

[gardener-robot-ci-1]

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.

[petersutter]

This PR makes sense together with PR #2476, however, I do not get the complete story. Is the goal to avoid overwhelming users when creating shoots and to control certain defaults (some of which cannot be changed after shoot creation), while giving users the freedom to change other settings later on (like hibernation, DNS config, addons, auto update)?

If there are CloudProfiles from different providers, I can change the infrastructure in the YAML tab. But this makes it confusing. Also you can create credentials for the infrastructure provider but you cannot select / change the infrastructure provider on the creation dialog. Or is the idea/recommendation to hide the infrastructure option only in landscapes where there is no other provider type?

[benedikt-haug]

This PR makes sense together with PR #2476, however, I do not get the complete story. Is the goal to avoid overwhelming users when creating shoots and to control certain defaults (some of which cannot be changed after shoot creation), while giving users the freedom to change other settings later on (like hibernation, DNS config, addons, auto update)?
If there are CloudProfiles from different providers, I can change the infrastructure in the YAML tab. But this makes it confusing. Also you can create credentials for the infrastructure provider but you cannot select / change the infrastructure provider on the creation dialog. Or is the idea/recommendation to hide the infrastructure option only in landscapes where there is no other provider type?

The goals of this PR is for the operator to be able to gain by configuration:

• free screen real estate if no choice is possible e.g. hide infrastructure section if only a single cloud provider exists or if choosing non-default isn't economically sensible
• nudge novice users e.g. if high-availability is the configured default (possible by the other PR), disabling this is generally not intended by the cluster operator, thus hiding this section reduces potential for user errors
• save explanation effort by hiding advanced usecases e.g. addons which aren't actually supported for production or workerless clusters which are mainly useful for development purposes

[ghost]

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

[ghost]

@benedikt-haug You need rebase this pull request with latest master branch. Please check.

[benedikt-haug]

/remove-lifecycle rotten

[ghost]

@benedikt-haug Command /remove-lifecycle is not known.

[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

[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 rotten
• Close this PR with /close

/lifecycle rotten

[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:

• Reopen this PR with /reopen
• Mark this PR as active with /lifecycle active
• Mark this PR as fresh with /remove-lifecycle rotten

/close

[gardener-prow]

@gardener-ci-robot: Closed this PR.

Details

In response to this:

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:

• Reopen this PR with /reopen
• Mark this PR as active with /lifecycle active
• Mark this PR as fresh with /remove-lifecycle rotten

/close

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.

[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.

[gardener-prow]

Adding label do-not-merge/contains-merge-commits because PR contains merge commits, which are not allowed in this repository.
Use git rebase to reapply your commits on top of the target branch. Detailed instructions for doing so can be found here.

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.

[gardener-prow]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign grolu for approval. For more information see the Code Review Process.

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

Details

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

[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.