-
Notifications
You must be signed in to change notification settings - Fork 801
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
Make Alpha & Beta CRD declaration consistent. #2982
Make Alpha & Beta CRD declaration consistent. #2982
Conversation
@@ -293,7 +293,7 @@ type GameServerStatus struct { | |||
// +optional | |||
Players *PlayerStatus `json:"players"` | |||
// (Alpha, SafeToEvict feature flag) Eviction specifies the eviction tolerance of the GameServer. | |||
Eviction Eviction `json:"eviction,omitempty"` | |||
Eviction *Eviction `json:"eviction,omitempty"` |
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.
@zmerlynn just noting I made this a pointer to be consistent with all other Alpha/Beta properties added to a CRD.
(I can't find the best practice doc I originally referenced for this approach.)
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.
Hmm, I saw that the others were but actually didn't understand why. It makes sense if they're nullable
, but this field doesn't need to be nullable, I don't think.
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.
Aha, found the reference I was looking for:
https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#optional-vs-required
Having it be a non pointer means that if the feature flag is off, there is still some kind of data stored in etcd (probably a lot of empty strings, since that's the default). Whereas if it's a pointer, there is nothing to serialise/deserialise.
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.
Actually, this is an optional field no -- I mean, the end user doesn't have to set it? So we should probably mark it as such.
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.
Yes, I was just about to point out that by those conventions, we should add the +optional
as well. But the concept LGTM - will give this a more thorough review in a bit (catching up).
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.
All good - no rush. I'll add in the +optional
here as well.
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.
I approved but would like to see this before it goes in. :)
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.
Done!
Build Succeeded 👏 Build Id: 1fd9f5dd-abe3-48b1-bc24-55855a00a87e 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, zmerlynn 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 |
We realised that with the CRD schema application being hidden behind a feature flag in the helm CRD yaml, then if the feature flag was turned off, an end user wouldn't get a validation error since the values passed in would be pruned by the K8s control plane. To make thins consistent across Alpha CRD values: * Alpha & Beta schemas are always available within the CRD definitions. * Validation checks are in place for the feature flag (no change needed) * Alpha & Beta CRD values are pointers, so they can be nullable (this required a change in Eviction handling and ApiHooks interface) * Some general cleanup of comments and descriptions in the schema.
a84a8d5
to
39f8c83
Compare
New changes are detected. LGTM label has been removed. |
Build Failed 😱 Build Id: 692c3738-2383-4a5c-a0f9-8a008844d935 To get permission to view the Cloud Build view, join the agones-discuss Google Group. |
Oh no, too many concurrent builds, never became the older PR in queue.
|
Build Succeeded 👏 Build Id: b8c07c90-8488-423f-9a3b-e2f0be3888ba 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:
|
Build Succeeded 👏 Build Id: 3f5c0caf-078c-4d77-ab3b-149237dbdded 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 cleanup
What this PR does / Why we need it:
We realised that with the CRD schema application being hidden behind a feature flag in the helm CRD yaml, then if the feature flag was turned off, an end user wouldn't get a validation error since the values passed in would be pruned by the K8s control plane.
To make thins consistent across Alpha CRD values:
Which issue(s) this PR fixes:
Special notes for your reviewer: