Tomasz Prus

Totally agree, patching in this library should work in the same way as in the kubernetes-client. I wasn't aware of the differences but as you noticed both behavior are problematic....

There is a PR to track https://github.com/kubernetes-client/python/pull/959 - it's already prepared and waits for review.

Thanks for reporting it.

Hi @JacobHenner Using the resource version was also discussed in the official library: https://github.com/kubernetes-client/python/issues/819 We can use the resource version as you suggest and implement the list-and-watch pattern but the...

Informer sounds as a really good idea. It looks it's the only way to handle reconnection, using resource version properly without notifying about the same events. IMO it should be...

Thanks for your reply. I agree with you, the part of your library related to the Watch can be moved here to fix the base library - better reconnect handling,...

Hi @horazont I'm afraid this refactoring won't be easy. Serialize() calls __serialize() which uses some class attributes: https://github.com/tomplus/kubernetes_asyncio/blob/master/kubernetes_asyncio/client/api_client.py#L304 And what's more it's auto-generated by openapi-generator so we have to change...

Changing generator is not an easy, especially if you want to be backward compatible. Do you consider using `attribute_map`s ? Each model has it. For instance: https://github.com/tomplus/kubernetes_asyncio/blob/master/kubernetes_asyncio/client/models/v1_pod_status.py#L51 I think, we...

I'd like to keep this client similar to the official client as possible. Are we sure that empty line means that server is disconnected? I don't see such checks in...

I got it, the official client "ignore" empty lines. In my opinion it's better if a library does mandatory retries to simplify end-client's code.