Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SharedInformerFactory, but for proto #3141

Open
codefromthecrypt opened this issue Mar 1, 2024 · 1 comment
Open

SharedInformerFactory, but for proto #3141

codefromthecrypt opened this issue Mar 1, 2024 · 1 comment

Comments

@codefromthecrypt
Copy link
Contributor

codefromthecrypt commented Mar 1, 2024

It seems that the SharedInformerFactory is designed for the openapi client, with the CallGenerator returning an okhttp3.Call.

ProtoClient doesn't seem designed in way to hook in the same way, at least at the moment, as it doesn't return okhttp3.Call. Rather, it invokes a request synchronously which wouldn't work with watches.

I'm not sure would be natural for it to return io.kubernetes.client.openapi.ApiException from generate, but that could be fine since ProtoClient depends on the openapi generated ApiClient anyway.

I think it could be something we can rejig to make it happen, by changing SharedInformerFactory or extracting some base class from it. This wouldn't unhook the gson dependency as still ApiClient pins it, but it could be possible to still use the proto infrastructure and drive informers more efficiently.

@brendandburns
Copy link
Contributor

Happy to have work done here. As expressed elsewhere, ProtoClient was hacked together a long time ago (before SharedInformerFactory, fwiw) and then has mostly lain dormant.

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

No branches or pull requests

2 participants