Skip to content
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

Allow to extend generated clients with custom verbs #16019

Merged

Conversation

mfojtik
Copy link
Contributor

@mfojtik mfojtik commented Aug 28, 2017

We need this in order to generate client calls like .Instantiate() or .Secrets() (for image stream secrets).
In upstream, this will allow to generate UpdateStatus which is currently "guessed" by checking for the presence of ".Status" field in the resource. It also allows to generate custom .Scale(...) in autoscaler.

Additionally this allows to send requests to sub-resources but also allows to override the input and result types for existing client calls or for extended client calls. The extended client calls are generated to the main client interface.

The final syntax is:

//+genclient:method=Instantiate,verb=create,subresource=instantiate,input=DeploymentRequest,output=DeploymentConfig

(the input/result types will allow to provide full import path, see the checklist)

TODO

  • Finalize the tag syntax
  • Allow cross-group type references for input/result type overrides
  • Fix the fake generator
  • Move this PR upstream and demonstrate this on .Scale() and .UpdateStatus()

@openshift-merge-robot openshift-merge-robot added the size/L Denotes a PR that changes 100-499 lines, ignoring generated files. label Aug 28, 2017
@openshift-merge-robot openshift-merge-robot added approved Indicates a PR has been approved by an approver from all required OWNERS files. needs-api-review labels Aug 28, 2017
@mfojtik
Copy link
Contributor Author

mfojtik commented Aug 28, 2017

@sttts @deads2k not ideal but somewhat working...

  • I tried to avoid copying the templates because I hate having the same function bodies templates copied into two places (although for sub-resources the body is different). I might end up add some conditional to original template to add sub resource
  • The string.Replace() is clunky but I dunno if there is a better way without rewriting the the original templates (maybe I should do that)

This need more work, but want to share WIP to get some early feedback...
(also this should probably be opened upstream, but I would like to have this downstream first to unblock our effort to remove legacy client).

@@ -123,6 +123,7 @@ const (
)

// +genclient
// +genclient:createInstantiateVerb=subresource=instantiate,input=DeploymentRequest
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This only works if DeploymentRequest is in the same package (does not work for external types or kapi / etc.) ...

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This only works if DeploymentRequest is in the same package (does not work for external types or kapi / etc.)

One our our use-cases is Scale (in autoscaling) and another is ImageSecrets or some such (in the core API group). Could we provide a full package name or something?

@bparees
Copy link
Contributor

bparees commented Aug 28, 2017

/unassign

func parseClientExpansions(tags map[string][]string) ([]expansion, error) {
ret := []expansion{}
for name, values := range tags {
if !strings.HasPrefix(name, "genclient:") || !strings.HasSuffix(name, "Verb") {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"genclient:" is worth a constant

name = strings.TrimPrefix(name, "genclient:")
exp := expansion{}
for _, supportedVerb := range SupportedVerbs {
if strings.HasPrefix(name, supportedVerb) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this looks fuzzy. Can't we be more precise with matching?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sttts at this point we only matched everything that starts with the supported verb and has *Verb suffix. Everything between is considered as expansion verb name. Dunno if there is a better way other than regexp.

continue
}
exp.VerbName = strings.TrimSuffix(strings.TrimPrefix(name, exp.VerbType), "Verb")
if len(values[0]) > 0 {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

are we sure there are values?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do I remember right that multiple tag line give you multiple values here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, if you repeat the same tag (same verb) with different configuration it will give you multiple values... i'm not sure if we want to support it... something like this looks like something we don't want to recommend?

// +genclient:createFooVerb=subresource=foo
// +genclient:createFooVerb=output=Foo

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nvmd. this actually works well if I move this into a for _, v := range values {} loop... so people can use this in multi-line if they really want

return ret, validateClientGenTags(values)
}

func parseClientExpansions(tags map[string][]string) ([]expansion, error) {
ret := []expansion{}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

var ret []expansion. Then you don't need the if at the bottom.

@mfojtik
Copy link
Contributor Author

mfojtik commented Aug 29, 2017

@sttts @deads2k PTAL

This generates what we need and we can use this to produce updateStatus as well (which is a sub-resource) and also the Scale() for autoscaling...

This is missing the fake client (it won't conform the interface right now, but this is also broken with normal expansions, I will try to fix it).

@mfojtik mfojtik changed the title WIP: Add expansion generator to client-gen WIP: Allow to extended generate clients with custom verbs Aug 29, 2017
@mfojtik
Copy link
Contributor Author

mfojtik commented Aug 29, 2017

@sttts syntax updated :)

@openshift-merge-robot openshift-merge-robot added size/XL Denotes a PR that changes 500-999 lines, ignoring generated files. and removed size/L Denotes a PR that changes 100-499 lines, ignoring generated files. labels Aug 29, 2017
@mfojtik
Copy link
Contributor Author

mfojtik commented Aug 29, 2017

@deads2k @sttts finalized this (fake generate fake methods, cross-imports works, etc). This should now have everything OpenShift need to add missing methods, I will start moving this upstream tomorrow.

PTAL generated methods and the generator changes.

obj, err := c.Fake.
$if .namespaced$Invokes($.NewListAction|raw$($.type|allLowercasePlural$Resource, $.type|allLowercasePlural$Kind, c.ns, opts), &$.type|raw$List{})
$else$Invokes($.NewRootListAction|raw$($.type|allLowercasePlural$Resource, $.type|allLowercasePlural$Kind, opts), &$.type|raw$List{})$end$
$if .namespaced$Invokes($if .subresource$$.NewListSubresourceAction|raw$$else$$.NewListAction|raw$$end$($.type|allLowercasePlural$Resource, $if .subresource$"$.subresourcePath$",$end$$.type|allLowercasePlural$Kind, c.ns, opts), &$.resultType|raw$List{})
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sttts this is hell.

@mfojtik
Copy link
Contributor Author

mfojtik commented Aug 30, 2017

(no need to api review, this is just adding genclient tags, not modifying API)

@mfojtik mfojtik added api-approved and removed approved Indicates a PR has been approved by an approver from all required OWNERS files. needs-api-review labels Aug 30, 2017
@openshift-merge-robot openshift-merge-robot added approved Indicates a PR has been approved by an approver from all required OWNERS files. needs-api-review and removed approved Indicates a PR has been approved by an approver from all required OWNERS files. labels Aug 30, 2017
@dobbymoodge
Copy link
Contributor

/retest

@mfojtik
Copy link
Contributor Author

mfojtik commented Aug 30, 2017

@Kargakis seems like the @openshift-merge-robot doing crazy things :)

@0xmichalis
Copy link
Contributor

@Kargakis seems like the @openshift-merge-robot doing crazy things :)

It actually is doing the right thing: adding the approved label because you removed it and the PR is approved, and adding the needs-api-review label because again you removed it. :) The SQ will not block on needs-api-review. We can improve the path-label munger in the future to add labels only on PR creation which will allow us to remove them afterwards.

@mfojtik
Copy link
Contributor Author

mfojtik commented Aug 31, 2017

/test extended_conformance_gce

@mfojtik
Copy link
Contributor Author

mfojtik commented Aug 31, 2017

/test cmd

seems like server failed to start?

@mfojtik
Copy link
Contributor Author

mfojtik commented Aug 31, 2017

/test extended_conformance_gce

@mfojtik
Copy link
Contributor Author

mfojtik commented Aug 31, 2017

/retest

@sttts
Copy link
Contributor

sttts commented Sep 1, 2017

/lgtm

If there are changes in the upstream PR, it shouldn't be hard to backport or wait for the next rebase.

@openshift-ci-robot openshift-ci-robot added the lgtm Indicates that a PR is ready to be merged. label Sep 1, 2017
@openshift-merge-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: mfojtik, sttts

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 /approve in a comment
You can cancel your approval by writing /approve cancel in a comment

@openshift-merge-robot
Copy link
Contributor

Automatic merge from submit-queue

@openshift-merge-robot openshift-merge-robot merged commit e765e9c into openshift:master Sep 1, 2017
@mfojtik mfojtik deleted the codegen-expansion-tags branch September 5, 2018 21:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api-approved approved Indicates a PR has been approved by an approver from all required OWNERS files. lgtm Indicates that a PR is ready to be merged. needs-api-review size/XL Denotes a PR that changes 500-999 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants