Python: Implement an Informer in python-client

Created on 8 Jul 2019  路  9Comments  路  Source: kubernetes-client/python

https://github.com/kubernetes/client-go has an Informer implementation. Internally it leverages a watcher of some collection of resources, continually streams changes (add/modify/delete events), reflects the resources into a downstream store (cache), handles connectivity drops, and periodically does a full resync. This all happens on some background thread (goroutine). A client of the informer is free to iterate over that stored cache without concern for how it's populated, and immediately get (possibly outdated) state.

Applications using https://github.com/kubernetes-client/python that want a local store of resources reflecting some in-cluster state need to concern themselves with those lower-level details. There's a lot of room for error.

On 2019-06-25, go#28 added a simple informer implementation to the openapi-generated client for Golang. It defines a Cache struct, with both a list of all objects and event handler callbacks that a consumer could register.

https://github.com/kubernetes-client/python should contain a similar implementation.

People have been talking about this a bit in various places.

help wanted lifecyclfrozen

All 9 comments

https://github.com/kubernetes-client/python should contain a similar implementation.

Philosophical consensus: _should_ the openapi-generated client libraries contain implementations of higher-level abstractions like this?

/cc

Any updates on this issue?

I wrote a SharedIndexInformer in Python after ~4000 lines of code including tests by directly translating it, its dependencies, and unit tests from client-go. I could share it but would want to be sure licensing/copyright isn't an issue; maybe it's ok as long as the "Kubernetes Authors" license header is on each translated file and the license is Apache? Also, I'm not sure if it's fit for this client:

  • It uses asyncio (and isn't thread-safe) and currently requires Python 3.7. I think it would make sense to add types because it's relatively complex
  • The APIs would need some work. They aren't always Pythonic because I focused on translating it first
  • I got an example working with a kind cluster but haven't tried to measure its performance. There may be stray tasks as of now
  • I'm missing context about client-go such as knowledge about technical debt that shouldn't be replicated. In general I'm not sure if it makes sense to maintain a Python version of DeltaFIFO, Reflector, and SharedIndexInformer...

Is there any interest in such a translation? Would licensing be a concern?

@alanjcastonguay if you aren't actively working on this, it may make sense to un-assign yourself from this issue. That way any would-be contributors won't have to wonder whether work is in progress before making their own attempt.

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

I pushed hacky junk to https://github.com/alanjcastonguay/python-base/commits/master - anyone want to help?

There's a lot at https://github.com/tbarrella/aiok8s, although I realized I probably won't be able to maintain it right now...

/lifecycle frozen

Was this page helpful?
0 / 5 - 0 ratings