-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
⚠️ adding multi namespaces cache #267
⚠️ adding multi namespaces cache #267
Conversation
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.
overall looks pretty solid. couple of comments inline, but it's pretty simple and straightforward to understand. Needs godoc on the internal objects, plus a bit more explanation of when you might want to use this, but in general 👍
9ad3d39
to
2f6a0b3
Compare
5c59791
to
a6adef3
Compare
a6adef3
to
35bbe4b
Compare
35bbe4b
to
b8dca46
Compare
Drive-by comment: I think this is great and would love to see it merged 🎉 |
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.
Need rebase.
pkg/cache/multi_namespace_cache.go
Outdated
if err != nil { | ||
return err | ||
} | ||
return json.Unmarshal(data, list) |
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 avoid marshal and then unmarshal to improve performance?
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 don't have a good way to do this when say someone is asking for a PodList
that I can think of.
Maybe we could do some reflection bits to make sure that the Items
field is there and use the scheme to create a new Object each time. I don't know how much better performance this would be though, WDYT?
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.
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 the code snippet you linked look reasonable. I believe it can improve performance by avoiding some unnecessary work.
But what confused me is why you treat ResourceVersion
specially. How about other metadata
fields?
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 here was my thinking:
-
SelfLink string - would think that this also does not make sense because we are combining multiple calls into one list. There is not a link that one could call to get the same list. This is also optional, so I figured it was fine to ignore.
-
Continue string - I think this also does not make a ton of sense because we should be handling this value in the cache by getting all the values. I would imagine that this is not necessary to set.
and the only other field is ResourceVersion which we will need.
Does that make sense?
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 makes sense.
Re. Continue string
, I found we currently don't support it in controller-runtime's ListOptions comparing to upstream ListOptions. So I guess we don't need to worry about it ATM.
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.
@droot @DirectXMan12 thoughts regarding the reflection bits linked 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.
I am pushing up an even better implementation in my mind. It will use api-machinery to manipulate the list, instead of using reflection directly.
}(ns, cache) | ||
} | ||
<-stopCh | ||
return nil |
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.
Should the multiNamespaceCache
main goroutine wait for each cache goroutine to finish before returning?
Or it doesn't matter?
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 don't think that it matters, just following the pattern that I think we started here:
https://github.com/kubernetes-sigs/controller-runtime/blob/master/pkg/cache/internal/deleg_map.go#L60-L62
Thoughts?
b8dca46
to
5559c19
Compare
@DirectXMan12 or @mengqiy can you guys re-start the build I think it was a flake. |
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.
Using apimachinery helpers make it look much better!
e2d83e8
to
72316bb
Compare
* Add Multinamespace Cache type *⚠️ Change the GetInformer methods to return a controller runtime Informer interface * Add multinamespace Informer type to handle namespaced infromers *⚠️ move NewCacheFunc from manager package to Cache pacakge
72316bb
to
fc804a4
Compare
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED Approval requirements bypassed by manually added approval. This pull-request has been approved by: shawn-hurley 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 |
Before fc804a4 (kubernetes-sigs#267), the `cache.Informers` interface methods returned `k8s.io/client-go/tools/cache.SharedIndexInformer`s which were by default compatible with the built-in `source.Informer`. Users could create arbitrary `cache.Cache` instances (or get them from the `Manager`) and then use `controller.Watch` to drive a controller with a `source.Informer` from the `cache.Cache`. With fc804a4, the `cache.Informers` interface was changed to return `cache.Informer` instances; however, `source.Informer` was not updated to accept a `cache.Informer`, and so users can no longer use the built-in `source.Informer` with `cache.Cache`. The `cache.Informer` interface appears to satisfy the needs of `source.Informer`. This commit broadens `source.Informer` to accept a `source.Informer`, restoring the prior capability while remaining compatible with `SharedIndexInformer` use.
Before fc804a4 (kubernetes-sigs#267), the `cache.Informers` interface methods returned `k8s.io/client-go/tools/cache.SharedIndexInformer`s which were by default compatible with the built-in `source.Informer`. Users could create arbitrary `cache.Cache` instances (or get them from the `Manager`) and then use `controller.Watch` to drive a controller with a `source.Informer` from the `cache.Cache`. With fc804a4, the `cache.Informers` interface was changed to return `cache.Informer` instances; however, `source.Informer` was not updated to accept a `cache.Informer`, and so users can no longer use the built-in `source.Informer` with `cache.Cache`. The `cache.Informer` interface appears to satisfy the needs of `source.Informer`. This commit broadens `source.Informer` to accept a `cache.Informer`, restoring the prior capability while remaining compatible with `SharedIndexInformer` use.
Before fc804a4 (kubernetes-sigs#267), the `cache.Informers` interface methods returned `k8s.io/client-go/tools/cache.SharedIndexInformer`s which were by default compatible with the built-in `source.Informer`. Users could create arbitrary `cache.Cache` instances (or get them from the `Manager`) and then use `controller.Watch` to drive a controller with a `source.Informer` from the `cache.Cache`. With fc804a4, the `cache.Informers` interface was changed to return `cache.Informer` instances; however, `source.Informer` was not updated to accept a `cache.Informer`, and so users can no longer use the built-in `source.Informer` with `cache.Cache`. The `cache.Informer` interface appears to satisfy the needs of `source.Informer`. This commit broadens `source.Informer` to accept a `cache.Informer`, restoring the prior capability while remaining compatible with `SharedIndexInformer` use.
Before fc804a4 (kubernetes-sigs#267), the `cache.Informers` interface methods returned `k8s.io/client-go/tools/cache.SharedIndexInformer`s which were by default compatible with the built-in `source.Informer`. Users could create arbitrary `cache.Cache` instances (or get them from the `Manager`) and then use `controller.Watch` to drive a controller with a `source.Informer` from the `cache.Cache`. With fc804a4, the `cache.Informers` interface was changed to return `cache.Informer` instances; however, `source.Informer` was not updated to accept a `cache.Informer`, and so users can no longer use the built-in `source.Informer` with `cache.Cache`. The `cache.Informer` interface appears to satisfy the needs of `source.Informer`. This commit broadens `source.Informer` to accept a `cache.Informer`, restoring the prior capability while remaining compatible with `SharedIndexInformer` use.
This will add the ability to set up a multi-namespace cache. This also has a backward incompatible change in the
Informers
interface which effects thecache
interface.This is based on the discussion from the BoF.
/cc @DirectXMan12 @mhrivnak @hasbro17
Wanted to get some early feedback before starting on tests.