-
Notifications
You must be signed in to change notification settings - Fork 1.2k
✨ Fakeclient: Add apply support #2981
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
Conversation
Skipping CI for Draft Pull Request. |
The Kubernetes project currently lacks enough contributors to adequately respond to all PRs. This bot triages PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
/lifecycle frozen |
@alvaroaleman: The In response to this:
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. |
The This bot removes
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /remove-lifecycle frozen |
ac5705d
to
b8202b9
Compare
b8202b9
to
71e305a
Compare
type multiTypeConverter struct { | ||
upstream []managedfields.TypeConverter | ||
} |
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.
Providing this composite type converter seems fine.
We have a different use case for a composite type converter in the apiserver for admission: https://github.com/kubernetes/kubernetes/blob/25e11cd1c143ef136418c33bfbbbd4f24e32e529/staging/src/k8s.io/apiserver/pkg/admission/plugin/policy/mutating/patch/typeconverter.go#L37. But the use case is different, it takes a single static type converter and an openapi client, instead of multiple underlying type converters, so it is not useful here.
I'd like to ensure we keep this implementation unexported. Maybe add some godoc to that effect?
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.
Yep makes sense, will do that
@@ -119,6 +123,7 @@ type ClientBuilder struct { | |||
withStatusSubresource []client.Object | |||
objectTracker testing.ObjectTracker | |||
interceptorFuncs *interceptor.Funcs | |||
typeConverters []managedfields.TypeConverter |
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.
nit: Can this simply be typeConverter managedfields.TypeConverter
? When multiTypeConverter
is needed, it should implement the managedfields.TypeConverter
interface and so can be initialized and used here?
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 on the builder and often times it will be needed to have more than one, as both in-tree and CRs are used
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 looks like a good approach. Left some minor feedback then LGTM.
The Kubernetes project currently lacks enough active contributors to adequately respond to all PRs. This bot triages PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten |
d6585af
to
e087e01
Compare
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
@@ -228,6 +237,29 @@ func (f *ClientBuilder) WithInterceptorFuncs(interceptorFuncs interceptor.Funcs) | |||
return f | |||
} | |||
|
|||
// WithTypeConverters sets the type converters for the fake client. The list is ordered and the first | |||
// non-erroring converter is used. A type converter must be provided for all types the client is used |
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.
Under which exact circumstances must these be provided?
Only if SSA with custom types is used with the fake client? (based on the unit test it looks like Unstructured also works without setting TypeConverters)
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 is always requiered if the FieldManagedObjectTracker is used, it seems to error out on all of its methods if the typeConverter doesn't handle a given type
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 think I'm missing something.
So if I'm using the fake client today with my own CRDs, this will now break if I don't start setting type converters for them? This would break a lot of people
(FieldManagedObjectTracker is always used if objectTracker is not explicitly set, right?)
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.
So if I'm using the fake client today with my own CRDs, this will now break if I don't start setting type converters for them? This would break a lot of people
No it will not break. SSA might not work correctly due to the inferencing type converter, but that is all.
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.
Okay, can we make this slightly clearer please? The current comment is
A type converter must be provided for all types the client is used for, otherwise it will error.
I'm not sure if folks will infer that correctly otherwise
Nice! Thx for working on this. My comments are mostly around improving test coverage and godoc a bit |
@tomasaschan @fsommar could you please find a different place for your comments that are not about feedback to the code changes in here to avoid polluting this? Thanks! |
c33ac89
to
04c0089
Compare
@alvaroaleman Last one from my side: #2981 (comment) |
b83e359
to
2f94e55
Compare
This change adds apply support into the fake client. This relies on the upstream support for this which is implemented in a new [FieldManagedObjectTracker][0]. In order to support many types, a custom `multiTypeConverter` is added. [0]: https://github.com/kubernetes/kubernetes/blob/4dc7a48ac6fb631a84e1974772bf7b8fd0bb9c59/staging/src/k8s.io/client-go/testing/fixture.go#L643
/lgtm |
LGTM label has been added. Git tree hash: 2b9d7c67fa6bf77671bde55014a360b49b49e0fd
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: alvaroaleman, 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 |
This change adds apply support into the fake client.
This relies on the upstream support for this which is implemented in a new FieldManagedObjectTracker. In order to support many types, a custom
multiTypeConverter
is added.The
FieldManagedObjectTracker
results inManagedFields
being set after any operations. As that would be a very breaking change, the fake client will by default unset them and allows to optionally leave them.Based on all existing tests still passing, I believe this change is fully backwards-compatible (But depends on breaking changes such as a very new client-go and apimachinery and #3228).
Fixes #2341