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

Calling Builder.For() multiple times loses previous apiTypes #1173

Closed
jim-minter opened this issue Sep 23, 2020 · 3 comments · Fixed by #1176
Closed

Calling Builder.For() multiple times loses previous apiTypes #1173

jim-minter opened this issue Sep 23, 2020 · 3 comments · Fixed by #1176
Assignees
Labels
good first issue Denotes an issue ready for a new contributor, according to the "help wanted" guidelines. help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines. kind/feature Categorizes issue or PR as related to a new feature. priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete.

Comments

@jim-minter
Copy link

At https://github.com/kubernetes-sigs/controller-runtime/blob/master/pkg/builder/controller.go#L74 , For latches the apiType of the For() call.

If a controller-runtime consumer calls Builder.For(foo).For(bar), then foo will be silently lost in favour of bar.

This contrasts with Owns' behaviour, where Builder.Owns(foo).Owns(bar) will append both foo and bar to an internal slice.

Judging by the code comment on For (For defines the type of Object being *reconciled*), it may not be intended for For to be called multiple times on a Builder. Nonetheless, the current behaviour can be confusing.

As a workaround, a consumer who wants to watch multiple apiTypes can use Watches(foo).Watches(bar) instead.

IMO it would be nice to make the behaviour here clearer, either:

  • by raising an error if For() is called and bldr.apiType is already set, or
  • by making apiTypes a slice and allowing For() to be called multiple times, as Owns() or Watches() is.
@DirectXMan12
Copy link
Contributor

You're never supposed to call For multiple times -- there should be one "root" type that you're reconciling generally. Saving an error and returning it on .Complete or .Build is a good idea though.

/good-first-issue
/kind feature
/priority important-longterm

@k8s-ci-robot
Copy link
Contributor

@DirectXMan12:
This request has been marked as suitable for new contributors.

Please ensure the request meets the requirements listed here.

If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-good-first-issue command.

In response to this:

You're never supposed to call For multiple times -- there should be one "root" type that you're reconciling generally. Saving an error and returning it on .Complete or .Build is a good idea though.

/good-first-issue
/kind feature
/priority important-longterm

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/test-infra repository.

@k8s-ci-robot k8s-ci-robot added kind/feature Categorizes issue or PR as related to a new feature. priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete. good first issue Denotes an issue ready for a new contributor, according to the "help wanted" guidelines. help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines. labels Sep 23, 2020
@prafull01
Copy link
Contributor

It looks simple enough. I can take it as my first issue for the controller-runtime.
/assign

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Denotes an issue ready for a new contributor, according to the "help wanted" guidelines. help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines. kind/feature Categorizes issue or PR as related to a new feature. priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants