-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
🌱 Add comments for spec/status/items #11870
base: main
Are you sure you want to change the base?
Conversation
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Hi @tsuzu. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
I've tried to run kal with Non-API resources (can be skipped with path)
Inline non-API resources(can ignore inline fields?)
Omitted fields should be ignored (Ignore if json tag is
|
Hi @tsuzu Hi @JoelSpeed Thanks. |
Agreed, these can be ignored
What makes these non-api? This goes back to our project to clean up the API packages to just contain APIs, but yes, if these are not API sourced, then we should skip them. Perhaps these could be updated anyway, seems there's a small number? I have a plan to implement "pathing" within KAL, so that we can find a list of all paths under which a field/type is used. If there are no paths to the field/type, then skipping linting the type is probably appropriate, that's on the backburner for now though.
What is the difference between these and the above types? These are types we construct to pass to kubeadm?
I assume that's fine, but lets make sure we understand what these types are first and whether @tsuzu wants to resolve them |
Agreed, thanks. |
@JoelSpeed If I read this correctly it's about these types: cluster-api/bootstrap/kubeadm/api/v1beta1/kubeadm_types.go Lines 289 to 295 in be7e672
Doesn't seem to make sense to add comments to anonymous structs that we use within a MarshalJSON func :) |
Ahh missed those, yeah that's probably something we can fix on the KAL side, i wouldn't expect it to be picking up anonymous functions in structs (though the custom marshalling there is also pretty wild/out there for an API package 👀 Would love to understand why that was written) |
That was written because of limitations of the json package. Please see: cluster-api/bootstrap/kubeadm/api/v1beta1/kubeadm_types.go Lines 276 to 284 in be7e672
|
Why do we need the rendered |
Because it is the only way to tell kubeadm to not set any taints |
I got it! I'll add comments for them. Update: Added
Thank you for the explanation. That's I wanted to say. |
api/v1beta1/cluster_types.go
Outdated
@@ -1047,7 +1047,9 @@ type Cluster struct { | |||
metav1.TypeMeta `json:",inline"` | |||
metav1.ObjectMeta `json:"metadata,omitempty"` | |||
|
|||
Spec ClusterSpec `json:"spec,omitempty"` | |||
// spec is the desired state of Cluster |
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.
// spec is the desired state of Cluster | |
// spec is the desired state of Cluster. |
Shouldn't these always end in a dot?
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.
Thanks for the review! Fixed with at 1281b4b
api/v1beta1/cluster_types.go
Outdated
@@ -1180,7 +1182,8 @@ func (f ClusterIPFamily) String() string { | |||
type ClusterList struct { | |||
metav1.TypeMeta `json:",inline"` | |||
metav1.ListMeta `json:"metadata,omitempty"` | |||
Items []Cluster `json:"items"` | |||
// items is the list of Cluster |
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.
// items is the list of Cluster | |
// items is the list of Clusters. |
I think it should always be plural for the items case. (also the dot?!)
1f4d683
to
1281b4b
Compare
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.
It seems the comment that other Spec has also starts with status.
api/v1beta1/cluster_types.go
Outdated
@@ -1047,7 +1047,9 @@ type Cluster struct { | |||
metav1.TypeMeta `json:",inline"` | |||
metav1.ObjectMeta `json:"metadata,omitempty"` | |||
|
|||
Spec ClusterSpec `json:"spec,omitempty"` | |||
// status is the desired state of Cluster. |
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.
// status is the desired state of Cluster. | |
// spec is the desired state of Cluster. |
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.
Ah, sorry. Fixed.
Thank you!
1281b4b
to
a0107cf
Compare
/ok-to-test |
What this PR does / why we need it:
Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)
format, will close the issue(s) when PR gets merged):A part of #11238
Once this PR is merged, all comments in API resources would start with serialized names.
Task list: #11238 (comment)
/area documentation