-
Notifications
You must be signed in to change notification settings - Fork 40.1k
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
Unify genclient tags and add more fine control on verbs generated #49192
Unify genclient tags and add more fine control on verbs generated #49192
Conversation
80056de
to
10605a5
Compare
This is based on discussion in openshift/origin#15236 |
Looks good. |
/cc @kubernetes/sig-api-machinery-api-reviews |
1659459
to
5baf941
Compare
} | ||
|
||
if !noMethods { | ||
if !tags.NoVerbs { | ||
sw.Do(resource, m) | ||
sw.Do(kind, m) | ||
} | ||
|
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.
Can we actually return here if its tags.NoVerbs
?
} | ||
|
||
if !noMethods && !readonly { | ||
sw.Do(patchTemplate, m) | ||
if !tags.NoVerbs && !tags.Readonly { |
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.
why is this if statement appearing again? It looks the same as above
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.
yeah, it makes sure the Patch() will be the last method (i can move it upper but that will reorder the methods... not sure if we care about that)
sw.Do(listUsingOptionsTemplate, m) | ||
} else { | ||
sw.Do(listTemplate, m) | ||
if !tags.NoVerbs { |
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.
returning early makes this block unconditional and early.
sw.Do(updateTemplate, m) | ||
// Generate the UpdateStatus method if the type has a status | ||
if genStatus(t) { | ||
if !tags.NoVerbs && !tags.Readonly { |
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.
After you generate getters, you can check if its readonly and just return, right?
|
||
readonly := extractBoolTagOrDie("readonly", t.SecondClosestCommentLines) == true | ||
if len(tags.OnlyVerbs) > 0 { |
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.
This block looks familiar. Why wouldn't this be done in the parse step?
} | ||
|
||
return sw.Error() | ||
} | ||
|
||
func skipVerb(m string, skippedVerbs []string) bool { |
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.
this is starting to look like a helper on the tags. Second time I've seen it.
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.
yeah I will move this to util
@@ -41,10 +43,14 @@ func (g *expansionGenerator) Filter(c *generator.Context, t *types.Type) bool { | |||
func (g *expansionGenerator) GenerateType(c *generator.Context, t *types.Type, w io.Writer) error { | |||
sw := generator.NewSnippetWriter(w, c, "$", "$") | |||
for _, t := range g.types { | |||
tags, err := util.ParseClientGenTags(t.SecondClosestCommentLines) | |||
if err != nil { | |||
fmt.Printf("Error parsing tags: %v", err) |
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.
if we can't parse, our return code should be non-zero. This seems to hide that.
I'm definitely in favor. I have a few minor comments and one concern (spread throughout the pull) about error handling. |
7920bbd
to
2ef6da9
Compare
@deads2k addressed all comments which also caused all clients to regenerate and reorder the functions :-) somebody should probably double-check that the generated clients are correct as I can have bug in the logic but it is hard to tell :-) |
if tags.NonNamespaced { | ||
sw.Do(structNonNamespaced, m) | ||
} else { | ||
sw.Do(structNamespaced, m) | ||
} | ||
|
||
if !tags.NoVerbs { | ||
if tags.NoVerbs { |
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.
This conditional switched. Need an if/else?
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 see
One comment on an if/else block. otherwise lgtm. |
2ef6da9
to
692fd56
Compare
@deads2k updated and regenerated |
0b1ea05
to
a3c8a57
Compare
@mfojtik doesn't build. |
@@ -57,6 +57,38 @@ func newAPIServices(c *ApiregistrationV1beta1Client) *aPIServices { | |||
} | |||
} | |||
|
|||
// Get takes name of the aPIService, and returns the corresponding aPIService object, and an error if there is any. |
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.
pkg/client/clientset_generated/clientset is removed in HEAD. Could you rebase?
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, but still failing to compile...
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.
Sorry, i didn't notice this file is in k8s.io/aggregator. Github hid the path. Please keep it.
Please only remove k8s.io/kubernetes/pkg/client/clientset_generated/clientset
, if there is any.
a3c8a57
to
06fdec3
Compare
i fixed the noMethods in types and regenerated stuff, but i'm getting this now... |
@mfojtik could you take a look why scale.go is generated? HEAD doesn't have any scale.go in informers/ |
@caesarxuchao ^^ do you remember if scale.go was removed manually or something? i can't see the reason why that file is generated (the client is set to have no methods (iow. noVerbs) |
lol :-) |
06fdec3
to
e6be341
Compare
@caesarxuchao ok I removed that file manually... seems like when I fixed the comment the file was not deleted automatically... lets see if the build pass now |
/lgtm |
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: deads2k, mfojtik, sttts Assign the PR to them by writing Associated issue requirement bypassed by: deads2k The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these OWNERS Files:
You can indicate your approval by writing |
Automatic merge from submit-queue (batch tested with PRs 49498, 49192) |
Automatic merge from submit-queue (batch tested with PRs 15468, 15446) Pick kubernetes kube-gen changes This PR picks the refactorings that were done upstream to move the generators to kube-gen and updates the generators we use to accomodate the new import paths. This also removes the wrappers for lister-gen and informer-gen as we can just use the upstream generator directly (I hope). This will be a base where I need to land the kubernetes/kubernetes#49192
Automatic merge from submit-queue list supported genclient tags and fix the format of the genclient tag This depends on: kubernetes/kubernetes#51638 for the `// +genclient:method`. Fixes the syntax of the generator after kubernetes/kubernetes#49192
This will change the syntax of the existing
genclient
tags be like this:The first one indicates the client will be generated from the struct below and the other tags are basically options to the genclient (which justify why they should be prefixed with
genclient:
)This also changes the
// +genclientstatus=false
to// +genclient:noStatus
to follow the pattern and also changes the// +noMethods=true
to// +genclient:noVerbs
as we call the REST operations verbs so it will make it consistent with terminology.In addition to existing options this patch also add two more to allow more fine-grained control on which verbs are going to be generated. This is extra useful for third-party projects (like OpenShift) where some resources does not implement full CRUD, but for example just "create" verb or "create" and "delete"...
To support that, you can use this syntax:
The first one will generate only create and delete functions and second one will generate full CRUD without "patch" actions. This somehow overlaps with the existing "readonly" tag, but I want to keep that tag in place as it reads better in some cases ;-)