- 
                Notifications
    You must be signed in to change notification settings 
- Fork 1.4k
🌱 Add comments for spec/status/items #11870
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
Conversation
| 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
          
        
      | 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
          
        
      | 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
          
        
      | 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 | 
| @JoelSpeed all good from your side? (then I'll take a final look) | 
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.
Couple of comments but otherwise LGTM
| I also took a look. Last finding #11870 (comment) then ready to merge | 
146307f    to
    1fd827a      
    Compare
  
    1fd827a    to
    f619679      
    Compare
  
    | Thank you! /lgtm | 
| LGTM label has been added. Git tree hash: 7ecd38f42c312c7ffa4f4f7de3e32b81a2dc88c5 | 
| [APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: sbueringer 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  | 
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