Skip to content
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
29 changes: 29 additions & 0 deletions sdk/builder.go
Original file line number Diff line number Diff line change
@@ -0,0 +1,29 @@
package sdk

type Builder interface {
// Name is the name of the operator.
Name(name string) Builder
// CRDName is the full name of the Custom Resource Resource that the operator operates on.
CRDName(crdName string) Builder
// 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)
    }
}

// Build builds an operator instance.
Build() (Operator, error)
}

type CallBacks interface {
// OnAdd notifies a creation of a Custom Resource.
OnAdd(obj interface{})
// OnUpdate notifies a update of an existing Custom Resource.
OnUpdate(oldObj, newObj interface{})
// OnDelete notifies a deletion of an existing Custom Resource.
OnDelete(obj interface{})
}

// NewOperatorBuilder creates a operator builder.
func NewOperatorBuilder() Builder {
// Implement me!
return nil
}
8 changes: 8 additions & 0 deletions sdk/operatorSDK.go
Original file line number Diff line number Diff line change
@@ -0,0 +1,8 @@
package sdk

import "context"

type Operator interface {
// Start starts the operator.
Start(Context context.Context) error
}