Interest in a controller interface?

[ddieruf]

I was wanting to create a K8s controller using this client and saw that there are no formal provisions. Looking at the Java client they have a controller extension, as a separate project. If I rewrote that extension in csharp would there be interest in bringing it in?

[ddieruf]

As I get deeper I see they have the notion of informers. I don't believe csharp has that, correct?

[ddieruf]

I believe I can pull out the idea of an InformerFactory for a simple Watch function that accomplishes that same idea but is not very versatile.

[tg123]

#351 #347
check out unmerged PRs

[ddieruf]

Thank you @tg123. Wow looks like they were on a good path but things got a little complicated. It would be so nice to have an Rx based informer in this client. I really want to create a controller for my project but want to do it in the most up to date, efficient way.

[ddieruf]

Before I go too far with this I am going to evaluate using @falox approach here. It's a bit dated but could maybe be refreshed to something up to date.

[brendandburns]

I think there is definite interest, it has (as you see) gotten complicated in the implementation.

I think the right way to do this is to start small and incrementally build.

e.g. I would start with a Watch-based cache (basically us a List/Watch to maintain an in-memory live cache of the state of the API) once we get that merged, we can start building Informers and such on top of that.

But definitely eager to see this get built.

[ddieruf]

I totally agree with this approach. Further, I feel like we have quite a bit of this already created. It just needs to be organized as one thought. I would like to take a stab at that :)

[brendandburns]

That would be awesome!

[ddieruf]

For those reading along, here's the first PR.

#665

[ddieruf]

A quick update @brendandburns and @tg123, things are progressing well. I have a good async model and am making my way through tests.

I have chosen to get the entire informer pattern working with tests, but will break things up logically into PRs. It's a lot to digest.

[tillig]

I just started down the controller creation path myself. I'm working mine into the .NET generic host mechanism so the things being monitored are all handled by BackgroundService implementations, which takes care of app start/stop and other sorts of concerns. Unfortunately, I'm definitely having to replicate some of the Java and Go logic to handle things; it'd be nice to have more baked in, even if it was a separate package.

[IvanJosipovic]

There are two projects that help build .NET Operators.
https://github.com/buehler/dotnet-operator-sdk
https://github.com/containersolutions/dotnet-operator-sdk

Hope this helps.

[ddieruf]

I have this PR in queue - #682 - which introduces GenericK8sApi.

I have informers ready to go as well. Controllers are not too far behind. I hope we can have a proper controller pattern in the official client. Similar to Java client.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale