Gardener: Introduce shoot cluster purposes

Created on 17 Jan 2020  路  5Comments  路  Source: gardener/gardener

What would you like to be added:
Today, the Gardener Dashboard allows three purposes: production, evaluation, development. Though, these purposes are only added as a label during creation via the Dashboard. End-users using the programmatic Gardener API usually don't set it/it's not enforced.

Let's now introduce .spec.purpose in the Shoot specification and a fourth purpose testing. All of this should be validated in the Gardener API server and defaulted accordingly (evaluation should be default like in the Gardener Dashboard).

By this, end-users can classify their cluster purposes which allows us to behave differently based on the value.
Concretely, the first step we envision is that no monitoring and no logging stacks are deployed for testing shoots.

Why is this needed:
Firstly, we have the purpose since long and don't plan to get rid of it, so we should make it a first-class citizen in our API.
Secondly, for the behavioural change for testing shoots, the motivation is to reduce the number of PVCs/PVs per control plane in the seed, eventually leading to lower IaaS API calls and lower probability to run into rate limits.

/cc @vlerenc @dkistner @timuthy @zanetworker

kinenhancement prioritcritical

Most helpful comment

Concretely, the first step we envision is that no monitoring and no logging stacks are deployed for testing shoots.

Hmm, I can actually imagine that the TestMachinery would set the purpose testing for many clusters and still would use another purpose (probably evaluation) for other testruns as well (i.e. for testruns containing logging&monitoring tests, and for release tests where I guess we want the "full" cluster)
But I guess that you primarily had other stakeholders in mind which create shoots as part of their testing CI/CD pipeline on certain infrastructures :)

All 5 comments

/cc @gardener/dashboard-maintainers - you should not set the purpose label in the future (we will support this for backwards compatibility for quite some time, i.e., we will take the label's value as .spec.purpose if it's set (if an unknown value was specified we will choose the default)), but you should use this new .spec.purpose field.

Concretely, the first step we envision is that no monitoring and no logging stacks are deployed for testing shoots.

Hmm, I can actually imagine that the TestMachinery would set the purpose testing for many clusters and still would use another purpose (probably evaluation) for other testruns as well (i.e. for testruns containing logging&monitoring tests, and for release tests where I guess we want the "full" cluster)
But I guess that you primarily had other stakeholders in mind which create shoots as part of their testing CI/CD pipeline on certain infrastructures :)

Sure, but your use-case makes also sense, +1

Also, the scheduler can choose most idle seed for these testing shoots.

Ah, OK, that's another creative/interesting idea, too. :-)

Was this page helpful?
0 / 5 - 0 ratings