Client-go: Informer framework

[sttts]

To write third-party controllers having object stores and the informer framework would be very handy.

[sttts]

Object stores are included: https://github.com/kubernetes/client-go/tree/b7b3ea539440e6d0efc6ef4dab644108016788c0/1.4/tools/cache

[timothysc]

Many folks would like to refactor or eliminate the current informer entirely.

[deads2k]

Many folks would like to refactor or eliminate the current informer entirely.

Can you elaborate on this? I know that some people have suggested doing things differently, but what I've seen has only differed in implementation, nothing significant in the API interfaces. I also haven't seen much action on it.

[wojtek-t]

Yeah - I'm also completely not aware of people that want to remove informer (though we obviously can improve it)

[timothysc]

@hongchaodeng and @xiang90 and proposed a refactoring to the informer in the 1.4 cycle that was pushed out. I'd have to dig up the issue number.

s/Eliminate/Choose not to use - Some folks that have designed their own controllers, simply do not use the informer.

[wongma7]

Is this the proposal in question? https://github.com/kubernetes/kubernetes/issues/27519

+1 to this anyway, I would rather use the same thing upstream controllers use, whatever flaws it has, than attempt to roll my own

[deads2k]

Is this the proposal in question? kubernetes/kubernetes#27519

+1 to this anyway, I would rather use the same thing upstream controllers use, whatever flaws it has, than attempt to roll my own

That proposal isn't what kube uses. Kube uses the SharedInformers as they exist today. The proposal didn't interoperate well with the existing DeltaFifo structure that has done a reasonable job so far.

[lavalamp]

This was an oversight, we intended to include this library, too.

[lavalamp]

It looks like @mikedanese is moving it anyway, so it should show up soon.

[jimmidyson]

Any news on this? Chomping at the bit to migrate over to this & really would like the informer framework in place to simplify migration.

[mikedanese]

https://github.com/kubernetes/kubernetes/pull/32718 Merged. This should hit the 1.5 client once it's synced.

[jimmidyson]

So this client gets automatically synced from kube repo then? How often does that happen?

[lavalamp]

~ daily. But I need to approve a PR before the 1.5 client will show up here
:)

On Wed, Sep 21, 2016 at 8:28 AM, Jimmi Dyson [email protected]
wrote:

So this client gets automatically synced from kube repo then? How often
does that happen?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes/client-go/issues/4#issuecomment-248648187,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAnglguclN5PZIetrQUnIovIZdRFiLAIks5qsU06gaJpZM4J5tgT
.

[seh]

If I'm looking to confine my Kubernetes dependencies to this repository, what's a good replacement for workqueue.Interface from "k8s.io/kubernetes/pkg/util/workqueue”?

Type cache.FIFO from “k8s.io/client-go/1.4/tools/cache” is similar, but I don’t see a way to unblock a caller waiting on FIFO.Pop, nor a way to shut the FIFO down. Is there a better choice for replacing workqueue.Interface?

[fabxc]

@lavalamp The 1.5/ sub directory is in but it doesn't include Informers. They are neither in the staging path in kubernetes/kubernetes.

Anything we could do to speed this up? It's blocking/complicating some high priority stuff for us.

[caesarxuchao]

The informer will show up after https://github.com/kubernetes/kubernetes/pull/33334 gets merged.

We need to manually run staging/src/k8s.io/client-go/copy.sh to populate changes to the staging area, then they will be published to client-go.

[lavalamp]

@caesarxuchao can we include the workqueue, as well?

[seh]

I've been working today on porting my code that relies on workqueue to use cache.FIFO, with some awkwardness, so if workqueue could come across I'd stick with it.

[lavalamp]

Yeah, workqueue and cache.FIFO are somewhat different animals-- we should
include workqueue.

On Mon, Sep 26, 2016 at 9:54 AM, Steven E. Harris [email protected]
wrote:

I've been working today on porting my code that relies on workqueue to
use cache.FIFO, with some awkwardness, so if workqueue could come across
I'd stick with it.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes/client-go/issues/4#issuecomment-249628946,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAnglhDqHp2HQfWKLYhRmwu_M9mbETIYks5qt_jVgaJpZM4J5tgT
.

[seh]

I see that kubernetes/kubernetes#33334 merged today. Is it the case that the next run of _copy.sh_ will put the informer stuff into this repository?

[caesarxuchao]

33334 ran the copy.sh. The next run (every 12 hours) of the bot will push the change to client-go. workqueue is still missing though.

[seh]

Thar she blows! Commit 5974905c2ab2b6ff24107cbf7bc397d770a675da includes cache.NewInformer—though only in version 1.5, as hinted by @mikedanese earlier.

Should we expect it to arrive in the version 1.4 subtree soon, or is that out of scope?

[caesarxuchao]

Should we expect it to arrive in the version 1.4 subtree soon, or is that out of scope?

Depending on how bad people want it. It requires cherrypicking https://github.com/kubernetes/kubernetes/pull/32718 and https://github.com/kubernetes/kubernetes/pull/33334, i.e., it requires some labor.

[mqliang]

@caesarxuchao files under 1.5/tools/cache/ are in package testing, instead of cache, is it intended?

see https://github.com/kubernetes/client-go/blob/master/1.5/tools/cache/controller.go#L17

[caesarxuchao]

No, it's a bug. I'll take a look.

[seh]

@caesarxuchao, I'm not sure when it's safe for me to start using the 1.5 subtree. Is it guaranteed to work against a Kubernetes version 1.3 cluster? That hesitation is what had me using the 1.4 subtree.

[lavalamp]

The 1.5 subtree is backwards compatible. However, the go interface will not
be frozen until 1.5 is released, i.e., it's mutable--tracking head--until
then.

So if you use the 1.5 client, be aware that we may make interface changes
that require you to change your code. We haven't done this yet, but we
probably will.

I'm totally open to cherrypicking client changes into the 1.4 client
branch-- now that 1.4 is released we should be able to do that without
getting the evil eye from the release czar. Maybe after Chao fixes the
package name. :)

The thing we absolutely cannot do is change the interface in the 1.4
client--no changes there that will make folks who import it change their
code. We only make changes like that over version boundaries.

On Wed, Sep 28, 2016 at 6:06 AM, Steven E. Harris [email protected]
wrote:

@caesarxuchao https://github.com/caesarxuchao, I'm not sure when it's
safe for me to start using the 1.5 subtree. Is it guaranteed to work
against a Kubernetes version 1.3 cluster? That hesitation is what had me
using the 1.4 subtree.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes/client-go/issues/4#issuecomment-250160774,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAngljd_txC5GQEN3W3lXAeJ0kOnDRjDks5qumZPgaJpZM4J5tgT
.

[seh]

Thank you for the explanation. I would appreciate a back-port, should one arrive soon, but in the meantime I'll try using the 1.5 client and see how it goes.

[jimmidyson]

no changes there that will make folks who import it change their
code. We only make changes like that over version boundaries.

As you're versioning this in line with kubernetes itself, this obviously goes against semver. Not that semver is a panacea but at least it gives a feel for API stability.

[lavalamp]

Indeed, that's a great point. Maybe we should version the go client
independently. I've put this on my list of things to think about.

On Wed, Sep 28, 2016 at 10:35 AM, Jimmi Dyson [email protected]
wrote:

no changes there that will make folks who import it change their
code. We only make changes like that over version boundaries.

As you're versioning this in line with kubernetes itself, this is
obviously goes against semver. Not that semver is a panacea but at least it
gives a feel for API stability.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes/client-go/issues/4#issuecomment-250239868,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAnglhk5jZsGORqbnoopeI3JKj2TtYq7ks5quqV3gaJpZM4J5tgT
.

[fabxc]

As it's pulled together from the kubernetes repo, independent versioning would ultimately leek into that. Even if intentionally developing on the most recent version, having the the sanitized package layout is valuable.

Maybe it's simplest to stick with freezing together with kubernetes but calling the non-frozen version "nightly" or "head"?

[lavalamp]

We talked a fair amount about this at the API Machinery SIG just now. I
think we definitely need to make it more clear what we're doing here.

Note that we haven't actually broken compatibility between 1.4 and 1.5 yet
so technically we're still following semver :)

On Wed, Sep 28, 2016 at 11:07 AM, Fabian Reinartz [email protected]
wrote:

As it's pulled together from the kubernetes repo, independent versioning
would ultimately leek into that. Even if intentionally developing on the
most recent version, having the the sanitized package layout is valuable.

Maybe it's simplest to stick with freezing together with kubernetes but
calling the non-frozen version "nightly" or "head"?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes/client-go/issues/4#issuecomment-250249883,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAngltdkhzYiuugtc1ChQYeyX1Cq8m94ks5quqzigaJpZM4J5tgT
.

[caesarxuchao]

I'll keep it open until we move workqueue.

[lavalamp]

I'm not quite sure why github closed this?

[caesarxuchao]

informers and workqueue are in the master branch now. Closing.