You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Apr 7, 2020. It is now read-only.
With the new core.gardener.cloud/v1alpha1.Shoot API Gardener does no longer understand the provider-specifics, e.g., the infrastructure config, control plane config, worker config, etc.
This allows end-users to harm themselves and create invalid Shoot resources the Garden cluster. Errors will only become present during reconciliation part creation of the resource.
Also, it's not possible to default any of the provider specific sections. Hence, we could also think about mutating webhooks in the future.
As we are using the controller-runtime maintained by the Kubernetes SIGs it should be relatively easy to implement these webhooks as the library abstracts already most of the things.
We should have a separate, dedicated binary incorporating the webhooks for each provider, and a separate Helm chart for the deployment in the Garden cluster.
Similarly, the networking and OS extensions could have such webhooks as well to check on the providerConfig for the networking and operating system config.
ghost
added
lifecycle/stale
Nobody worked on this for 2 months (will further age and may be closed after 6 months of inactivity)
and removed
lifecycle/stale
Nobody worked on this for 2 months (will further age and may be closed after 6 months of inactivity)
labels
Jan 14, 2020
With the new
core.gardener.cloud/v1alpha1.Shoot
API Gardener does no longer understand the provider-specifics, e.g., the infrastructure config, control plane config, worker config, etc.This allows end-users to harm themselves and create invalid
Shoot
resources the Garden cluster. Errors will only become present during reconciliation part creation of the resource.Also, it's not possible to default any of the provider specific sections. Hence, we could also think about mutating webhooks in the future.
As we are using the controller-runtime maintained by the Kubernetes SIGs it should be relatively easy to implement these webhooks as the library abstracts already most of the things.
We should have a separate, dedicated binary incorporating the webhooks for each provider, and a separate Helm chart for the deployment in the Garden cluster.
Similarly, the networking and OS extensions could have such webhooks as well to check on the
providerConfig
for the networking and operating system config.Validating webhooks:
Mutating webhooks:
Part of gardener/gardener#308
The text was updated successfully, but these errors were encountered: