-
Notifications
You must be signed in to change notification settings - Fork 775
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GameServerSpec: Add PodTemplateSpec validation #1298
Comments
Well, I have tried to reuse the version of
|
What could cause errors in creating Pods, as could be found in https://github.com/kubernetes/kubernetes/blob/master/pkg/apis/core/validation/validation.go#L3194 :
|
Worth exploring: Another trick I saw (but now can't find again), that I thought was clever - run a dry run of a creation of a pod with the same details, and return any validation issues that it found. What we might want to do though is keep a cache of of specs that have been marked valid, so we can skip hitting the API all at once for the dry run steps. |
Another trick @luna-duclos put me onto: Using https://github.com/kubernetes-sigs/controller-tools/tree/master/cmd/controller-gen to generate the schema for the Pod: Docs: Which can then be included into the schema for Game Server template. This actually sounds very promising! |
This PR provides the mechanisms to pull core Kubernetes resource OpenAPI schemas out of the API, and customise and convert them into a format that is embeddable in our own CRD specifications. This has been used to extract OpenAPI schemas for `ObjectMeta`, and `PodTemplateSpec`, and then embedded in `GameServer` as well as parent CRDs. Also included in a new helm config option of `gameservers.podPreserveUnknownFields` in case a user needs to escape the field pruning on a Pod, or if PR causes a bug of any kind. Also worth noting, this is not comprehensive validation, and therefore I have not closed the the referenced issue. Work on googleforgames#1298
This PR provides the mechanisms to pull core Kubernetes resource OpenAPI schemas out of the API, and customise and convert them into a format that is embeddable in our own CRD specifications. This has been used to extract OpenAPI schemas for `ObjectMeta`, and `PodTemplateSpec`, and then embedded in `GameServer` as well as parent CRDs, creating a layer of validation for Pods definitions that are implemented via a GameServer. Also included in a new helm config option of `gameservers.podPreserveUnknownFields` in case a user needs to escape the field pruning on a Pod, or if PR causes a bug of any kind. Also worth noting, this is not comprehensive validation, and therefore I have not closed the the referenced issue. Work on googleforgames#1298
This PR provides the mechanisms to pull core Kubernetes resource OpenAPI schemas out of the API, and customise and convert them into a format that is embeddable in our own CRD specifications. This has been used to extract OpenAPI schemas for `ObjectMeta`, and `PodTemplateSpec`, and then embedded in `GameServer` as well as parent CRDs, creating a layer of validation for Pods definitions that are implemented via a GameServer. Also included in a new helm config option of `gameservers.podPreserveUnknownFields` in case a user needs to escape the field pruning on a Pod, or if PR causes a bug of any kind. Also worth noting, this is not comprehensive validation, and therefore I have not closed the the referenced issue. Work on googleforgames#1298
This PR provides the mechanisms to pull core Kubernetes resource OpenAPI schemas out of the API, and customise and convert them into a format that is embeddable in our own CRD specifications. This has been used to extract OpenAPI schemas for `ObjectMeta`, and `PodTemplateSpec`, and then embedded in `GameServer` as well as parent CRDs, creating a layer of validation for Pods definitions that are implemented via a GameServer. Also included in a new helm config option of `gameservers.podPreserveUnknownFields` in case a user needs to escape the field pruning on a Pod, or if PR causes a bug of any kind. Also worth noting, this is not comprehensive validation, and therefore I have not closed the the referenced issue. Work on googleforgames#1298
* CRD OpenAPI Spec for ObjectMeta & PodTemplateSpec This PR provides the mechanisms to pull core Kubernetes resource OpenAPI schemas out of the API, and customise and convert them into a format that is embeddable in our own CRD specifications. This has been used to extract OpenAPI schemas for `ObjectMeta`, and `PodTemplateSpec`, and then embedded in `GameServer` as well as parent CRDs, creating a layer of validation for Pods definitions that are implemented via a GameServer. Also included in a new helm config option of `gameservers.podPreserveUnknownFields` in case a user needs to escape the field pruning on a Pod, or if PR causes a bug of any kind. Also worth noting, this is not comprehensive validation, and therefore I have not closed the the referenced issue. Work on #1298 * Generated yaml for Schema improvements * Upgrade Helm to 3.5.0 Needed upgrade to fix bug wth upgrade. * Updates based on review - Fix for typo in license. - Fix comment in test to be more clear. - Rebase against master and regen index.yaml
'This issue is marked as Stale due to inactivity for more than 30 days. To avoid being marked as 'stale' please add 'awaiting-maintainer' label or add a comment. Thank you for your contributions ' |
This issue is marked as obsolete due to inactivity for last 60 days. To avoid issue getting closed in next 30 days, please add a comment or add 'awaiting-maintainer' label. Thank you for your contributions |
We are closing this as there was no activity in this issue for last 90 days. Please reopen if you’d like to discuss anything further. |
Is your feature request related to a problem? Please describe.
There were 2 validation of PodTemplateSpec added recently - for Labels and Annotations. This approach could be generalised for all fields in a PodTemplateSpec.
This could run system into a failure state without informing user that he choose wrong pod template.
For instance fleet mentioned below with resources requests.memory > limits.memory is a mistake and no pod could be created from such template.
Fleet would start to fire up new GameServers infinitely as in aforementioned bugs with Labels.
Describe the solution you'd like
Use a standard Validation logic as could be found here for a ReplicaSet:
https://github.com/kubernetes/kubernetes/blob/52d7614a8ca5b8aebc45333b6dc8fbf86a5e7ddf/pkg/apis/apps/validation/validation.go#L674
Describe alternatives you've considered
Additional context
Fleet which does not signalise of a failure config:
The text was updated successfully, but these errors were encountered: