[wip] sdk: add operator and builder interface #7
Conversation
| // APIVersion is the version from the groupVersion. | ||
| APIVersion(apiVersion string) Builder | ||
| // Callbacks registers the callbacks which notifies the creation, update, and deletion of any Custom Resource. | ||
| Callbacks(callBacks CallBacks) Builder |
There was a problem hiding this comment.
the callback should not be per resource based. it is a pain in the ass to ask the users to serialize the requests to avoid concurrency issues.
users should only need to implement a single sync func where all changes are serialized already by SDK. Users do not need to solve any concurrency issue.
There was a problem hiding this comment.
I see. that makes sense. i'll re-think the api def.
There was a problem hiding this comment.
the callback should not be per resource based.
What do you mean by not per resource based?
There was a problem hiding this comment.
So from what I understand related to xiang's comment on the other PR the idea is that there should not be separate callbacks/sync functions registered for each different custom resource, pods, secrets etc.
https://github.com/coreos/operator-sdk/pull/6/files#r167013090
The users would just watch for all the resources they need and all events(add,update, delete) would get sent to the main sync function and be handled by the user over there.
sdk.Watch(EtcdCluster)
sdk.Watch(Vault)
sdk.Watch(ConfigMap)
...
func sync(...) {
// Handle sync based for all resources and event types
}
There was a problem hiding this comment.
@hasbro17 exactly.
users only need to fill in sync func like this
func sync(objects []runtime.Object) {
switch {
case X:
handle(X)
}
}
|
This PR is causing too much distraction. I'm closing it now. |
…tream-dockerfile adding upstream docker file
Signed-off-by: Venkat Ramaraju <[email protected]>
4 participants
Initial thoughts on operator sdk interface.