Skip to content

Conversation

@hasbro17
Copy link
Contributor

An initial implementation of what the sdk Informer API NewKubeInformer() and RegisterInformer() could look like.

The main focus of this PR is the sdk Informer.
I've only added the other interfaces for Handler and Dispatcher to make sense of how the sdk passes Events from Informer->Dispatcher->Handler.

Going to add a diagram in the design doc to convey the overall structure.

dp.Run(ctx)
}

/*
Copy link

Choose a reason for hiding this comment

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

put this into doc.go or create example_test.go

```main.go
func main() {
sdk.RegisterInformer("play-informer", informer.NewKubeInformer(&Play{}))
sdk.RegisterInformer("pod-informer", informer.NewKubeInformer(&Pod{}))
Copy link

Choose a reason for hiding this comment

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

why not just sdk.watch("watch-pod", &Pod{})?

Copy link
Contributor

Choose a reason for hiding this comment

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

There will be two kinds of states to watch: k8s state and application state.
We need to provide an abstraction to extend inform events mechanism.

Copy link
Contributor

Choose a reason for hiding this comment

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

@xiang90 if I understand how informer works. it requires the restClient that's associated with the watched resource.
e.g:

	source := cache.NewListWatchFromClient(
		v.vaultsCRCli.VaultV1alpha1().RESTClient(),
		api.VaultServicePlural,
		v.namespace,
		fields.Everything())

Copy link

Choose a reason for hiding this comment

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

i do not quite understand. can you provide me an example?

Copy link
Contributor

Choose a reason for hiding this comment

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

nvm, i am thinking about a different issue.

Copy link

Choose a reason for hiding this comment

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

we should hide all the inform stuff for users if possible.

Copy link
Contributor

Choose a reason for hiding this comment

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

i do not quite understand. can you provide me an example?

Sure.
For example, we might have an informer that watches application API and triggers custom events, e.g. application is unhealthy or overloaded, which cannot be observed via k8s api.

we should hide all the inform stuff for users if possible.

Yes. We will provide a KubeInformer() which is the same mechanism you mentioned above.

Copy link
Contributor

Choose a reason for hiding this comment

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

@xiang90 I am thinking about this watch interface:

type Watchable struct {
	RESTClient rest.Interface
	Resource   string
	Namespace  string
}

type Client interface {
	Watcher(...Watchable) Watcher
}

But the Watchable is not elegant since it needs to know the RESTClient that's associating with the watched resource.

I thought about sdk.watch("watch-pod", &Pod{})?. I am not sure how to create informer internally just with the &Pod{} struct.

Copy link

Choose a reason for hiding this comment

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

For example, we might have an informer that watches application API and triggers custom events, e.g. application is unhealthy or overloaded, which cannot be observed via k8s api.

OK. let us worry about this later by creating a new func. WatchApplication or whatever. I do not want to overload one func.

Copy link

Choose a reason for hiding this comment

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

@fanminshi

watch(whatever, withNamespace(x), withFields(y)...). the options work exactly like what etcd/cleintv3 does and other projects in go do. that is the suggested way for go.

sdk.RegisterActor("kube-apply", actor.KubeResourceApply)
sdk.RegisterActor("kube-delete", actor.KubeResourceDelete)

sdk.RegisterHandle(stub.NewHandler())
Copy link

Choose a reason for hiding this comment

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


type Action struct {
Object Object
Actor string
Copy link

Choose a reason for hiding this comment

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

this should be just action (apply, delete, create, patch etc..). also type define the string.


type Event struct {
Object Object
ObjectExist bool
Copy link

Choose a reason for hiding this comment

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

should this also be action?


import "context"

type Object interface{}
Copy link

Choose a reason for hiding this comment

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

should this be k8s runtime.object?

Copy link

Choose a reason for hiding this comment

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

let us not worry about user defined event object for now.

Copy link
Contributor

Choose a reason for hiding this comment

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

Sounds good.

sdkTypes "github.com/coreos/operator-sdk/pkg/sdk/types"
)

type Dispatcher interface {
Copy link

Choose a reason for hiding this comment

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

Copy link
Contributor

Choose a reason for hiding this comment

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

HandleMux

@hasbro17
Copy link
Contributor Author

Going to remove the Dispatcher and Action type related code for now as that was just added to give the general idea.
We can implement it after we discuss the exact spec further in the design doc.

@hasbro17
Copy link
Contributor Author

On second thought, going to leave this PR as it is for the benefit of discussing the overall design. Going to push a new PR specifically for the informer implementation.

@hasbro17
Copy link
Contributor Author

Closing in favour of #9

@hasbro17 hasbro17 closed this Feb 14, 2018
VenkatRamaraju referenced this pull request in VenkatRamaraju/operator-sdk Mar 22, 2022
#8)

* Infer the image type (SQLite/FBC) based on the image label and handle FBC scenarios

Signed-off-by: rashmigottipati <[email protected]>
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