-
Notifications
You must be signed in to change notification settings - Fork 813
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
CRD OpenAPI Spec for ObjectMeta & PodTemplateSpec #1956
CRD OpenAPI Spec for ObjectMeta & PodTemplateSpec #1956
Conversation
Build Failed 😱 Build Id: 3222c780-8894-4cf7-aabd-3b7ddf40f31b To get permission to view the Cloud Build view, join the agones-discuss Google Group. |
4e59b2a
to
40bb824
Compare
Well this is a weird one, helm hangs on doing the upgrade. This is what I see when I enable debugging: - it just stops at the blank line, and never continues. The helm release is still marked as active, and successfully deployed.
|
Repro'd locally, but looks like an upgrade to Helm solved it. 🤞 |
Build Succeeded 👏 Build Id: 3a81777f-f10d-4ec4-a9e4-12407df7f542 The following development artifacts have been built, and will exist for the next 30 days:
A preview of the website (the last 30 builds are retained): To install this version:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My only concern here is that by expanding object meta (in particular) we add documentation for a ton of new fields which users really shouldn't care about. The extra validation may be useful, but I don't expect anyone using Agones will need anything other than labels and annotations, and now there are a bunch of other documented and validated fields each place we have metadata that only serve to distract from the fields that are relevant.
https://kubernetes.io/docs/reference/kubernetes-api/common-definitions/object-meta/ presents the fields nicely. Maybe folks will just read that and the validation is primarily for machine consumption. |
I would posit that we don't need to change any documentation above what we have now. Prior to 1.11 we did support the full ObjectMeta, so 1.11 is technically a regression in functionality (who knows who might want to add a finaliser to their Pod/GameServer one day????), and we have links to the existing Kubernetes reference documentation for ObjectMeta. We currently document ObjectMeta in the GameServer reference by pointing to https://v1-17.docs.kubernetes.io/docs/reference/generated/kubernetes-api/v1.17/#podtemplate-v1-core and letting people go from there. Similarly https://agones.dev/site/docs/reference/agones_crd_api_reference/#agones.dev/v1.GameServer points to the K8s reference as well, similarly in https://agones.dev/site/docs/reference/agones_crd_api_reference/#agones.dev/v1.GameServerTemplateSpec So I think our current docs have good coverage in this area.
That's a really nice page 👍 maybe that's something we can add in our docs instead of / in addition to the reference docs. |
Build Failed 😱 Build Id: 32a1ec5b-adef-45f9-a3fd-0573fdb26c77 To get permission to view the Cloud Build view, join the agones-discuss Google Group. |
Note to self when writing the release notes:
|
Build Succeeded 👏 Build Id: 292d17ff-8fdb-4f7c-8f37-b5a19834bab7 The following development artifacts have been built, and will exist for the next 30 days:
A preview of the website (the last 30 builds are retained): To install this version:
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: markmandel, roberthbailey The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
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
Needed upgrade to fix bug wth upgrade.
- Fix for typo in license. - Fix comment in test to be more clear. - Rebase against master and regen index.yaml
c6962b6
to
e47fc8b
Compare
New changes are detected. LGTM label has been removed. |
Build Succeeded 👏 Build Id: 81740574-83c6-4fc9-a0a4-b41f961bcbe8 The following development artifacts have been built, and will exist for the next 30 days:
A preview of the website (the last 30 builds are retained): To install this version:
|
What type of PR is this?
/kind feature
What this PR does / Why we need it:
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
, andPodTemplateSpec
, and then embedded inGameServer
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 escapethe field pruning on a Pod, or if PR causes a bug of any kind.
Which issue(s) this PR fixes:
Work on #1298
Special notes for your reviewer: