Generated client object is too heavy and causes significant slowdown to IDE

[macsux]

Autorest generated Kubernetes, IKubernetes, and KubernetesExtensions classes / interfaces put so many operations on to one object that using the current k8s client library causes a significant slowdown of any project where it is added, significantly degrading "full" IDEs like Visual Studio and Rider. Many of the generated methods can be completely eliminated by replacing them with a generics version such as the following: https://github.com/kubernetes-client/csharp/blob/fb8ef4f685215ad4bd5dbe5b91b68d41d3ab0213/src/KubernetesClient/IKubernetes.Generic.cs

Some proposals worth considering
a) eliminate synchronous methods generates in the extensions class (as with modern C# you should not be transitioning from async to sync as a matter of best practice - users can do it themselves if they need to)
b) replace all "standard" resource APIs with generic version (for core objects those that follow CRD conventions - this can include legacy non-group specific objects such as Pod)
c) consider splitting the interface into low level (one where methods return what is now WithHttpMessagesAsync) and high level (return actual deserialized objects).

Obviously this would be a breaking change, but the usability of the library has real effect on developer productivity ATM.

[tg123]

totally agree
nothing should slow down developer’s working environment.

but I did not feel such lag
do you have some vs plugins? I did not try rider yet.

[macsux]

I mainly use Rider, and I have resharper with visual studio. There's almost a second worth of lag for intellisense to come up when accessing IKubernetes/Kubernetes object. Also the reindexing of my own code seems to be much slower then usual (code highlighting, syntax validation). IMO it doesn't make much sense to have hardcoded methods against K8S API when the underlying API is very much extensible. A lot of CRDS are being created and having a uniform API that works for those and core K8S resources makes sense.

…

On Sat, Apr 4, 2020 at 3:29 PM Boshi Lian ***@***.***> wrote: totally agree nothing should slow down developer’s working environment. but I did not feel such lag do you have some vs plugins? I did not try rider yet. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#399 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAINFWHBH2CFDEDTQ6O3GYTRK6DDHANCNFSM4L6Y2X7Q> .

[brendandburns]

The general philosophy of these client libraries is to code generate them. If we want changes we need modify (or reconfigure if possible) the AutoRest project.

I haven't actually run into any problems myself (vs code + C# extension) even on a relatively underpowered machine (Surface Go)

[macsux]

@brendandburns c# library is actually hybrid as we use a secondary gen project as well, plus there are a number of hand coded methods already (exec). If you're open to it, I can take a stab at reconfigure AutoRest to

1. Not generate sync extension methods
2. Modify secondary gen project to strip out any methods in ikubernetes/kubernetes that follow 'standards' pattern, and instead rely on the 4 new methods in the PR mentioned above.
3. Model generation would stay the same

Vscode doesn't do nearly as much of code analysis as full IDEs so I totally expect it to be a non issue

[brendandburns]

If we think we can get down to standard create/update/delete methods that take generic objects, I'm open to it, I think the hard thing to do is to generate the HTTP path for a given object.

I don't want users to have to do something like:

create('/api/v1/pods/namespaces/default/mypod', podObject, ...)

But if we can get to create<V1Pod>(podObject) or something like that, that's cool.

[brendandburns]

Also, I'm not sure I'm ok w/ removing Sync methods, but we could move them into a separate IKubernetesSync or something like that.

[macsux]

Here's the "generic" implementation. It's already part of the open PR for informers #394

https://github.com/macsux/kubernetes-client-csharp/blob/feature/rx-informers/src/KubernetesClient/Kubernetes.Generic.cs

[admilazz]

But if we can get to create<V1Pod>(podObject) or something like that, that's cool.

I've implemented a generic, fluent model that looks like this (where c is the client). Each line generates a request:

c.New<V1Pod>() // list all pods in all namespaces
c.New<V1Pod>("ns") // list all pods in a namespace
c.New<V1Pod>("ns", "name") // list a single pod
c.New<V1Pod>("ns", "name").Delete() // delete a pod by name
c.New(pod, setBody: false).Delete() // delete a pod if you have the object already
c.New(pod).Put() // replace a pod
c.New<V1Pod>("ns").LabelSelector("X").FieldSelector("Y") // list pods with label and field selectors
c.New(pod).Subresource("status").Put() // update the status
etc...

It works with any resource type, plus custom types.

To execute any request so constructed, it's simply: r.ExecuteAsync(), or to execute and deserialize, r.ExecuteAsync<T>() etc. To do an atomic get-modify-update operation, you can do r.ReplaceAsync<T>(). I think it's got some other stuff...

EDIT: the PR is here: #406

[macsux]

Here's a recording I made of the kind of lag IKubernetes has with IntelliSense in Rider:
https://youtu.be/wWRfvndxJ_8

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close