-
Notifications
You must be signed in to change notification settings - Fork 0
Description
When it became clear that influxdata/telegraf-operator was no longer being maintained I created jmickey/telegraf-sidecar-operator and have been running it in production since (thousands of pods/sidecars).
It's not really a fork of influxdata/telegraf-operator, more of a rewrite I guess that takes a slightly different approach while addressing some important issues (1, 2) and more recently supporting some new features (e.g. influxdata/telegraf-operator#136). With full respect to the past creators and maintainters of influxdata/telegraf-operator, my implementation is a more robust and idiomatic (in a Kubernetes sense) solution.
The main difference is that the admission webhook no longer has side-effect external to the mutated pod (e.g. secret creation), rather this is handled by a pod controller that applies the secret after pod creation and configures an ObjectReference relationship between the pod and the secret so that the secret is automatically removed after pod deletion (you can't do this in admission because there is no pod ID yet).
Ultimately, while I don't mind maintaining jmickey/telegraf-sidecar-operator over the long term, I don't see the point in having two projects that solve the same problem if this project (InfluxCommunity/telegraf-operator) is also going to be maintained. I'm wondering if there is an opportunity to combine efforts here?