Skip to content

[wip] sdk: add operator and builder interface#7

Closed
fanminshi wants to merge 1 commit intooperator-framework:masterfrom
fanminshi:add_operators_interface
Closed

[wip] sdk: add operator and builder interface#7
fanminshi wants to merge 1 commit intooperator-framework:masterfrom
fanminshi:add_operators_interface

Conversation

@fanminshi
Copy link
Copy Markdown
Contributor

@fanminshi fanminshi commented Feb 8, 2018

Initial thoughts on operator sdk interface.

@fanminshi
Copy link
Copy Markdown
Contributor Author

cc/ @hasbro17 @hongchaodeng

Comment thread sdk/builder.go
// 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
Copy link
Copy Markdown

Choose a reason for hiding this comment

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

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.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

I see. that makes sense. i'll re-think the api def.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

the callback should not be per resource based.
What do you mean by not per resource based?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

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 
}

Copy link
Copy Markdown

@xiang90 xiang90 Feb 8, 2018

Choose a reason for hiding this comment

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

@hasbro17 exactly.

users only need to fill in sync func like this

func sync(objects []runtime.Object) {
    switch {
    case X:
        handle(X)
    }
}

@hongchaodeng
Copy link
Copy Markdown
Contributor

hongchaodeng commented Feb 8, 2018

This PR is causing too much distraction. I'm closing it now.
For design discussion, please move to https://docs.google.com/document/d/1GVvCc2UhCeK9T69hRRuOx8Pbz8CJNYZZviSbzWL1tMU/edit
For framework start entry point, this is gonna be solved in #6

shawn-hurley pushed a commit to shawn-hurley/operator-sdk that referenced this pull request Apr 23, 2019
…tream-dockerfile

adding upstream docker file
VenkatRamaraju referenced this pull request in VenkatRamaraju/operator-sdk Mar 22, 2022
Signed-off-by: Venkat Ramaraju <vramaraj@redhat.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants