Daniel Schierbeck

Only having compatibility with Kafka 2.1+ would be a non starter at this point, I believe. I could be persuaded otherwise if there's some kind of index of Kafka version...

This sounds like a problem in librdkafka.

Handling MessageSizeTooLargeException correctly is tricky, and we've yet to find a single, one-size-fits-all solution. I would advice trying to find the message that's causing the problem and skipping it. Unfortunately,...

> @dasch I think I found a bug in the compression. I fixed it in the second to last commit: [3ad0c04](https://github.com/zendesk/ruby-kafka/commit/3ad0c0447e96f13e8ca55fc407bc34ce0596ed84) Oh, should've read this before reviewing 😆 > Looks...

You might need to read up on how records are encoded: https://kafka.apache.org/documentation/#recordbatch

Looks like this change breaks the integration tests. I'm not quite sure how many people are using Kafka versions older than v1.1 – since there's no support for multiple versions...

@grosser am I wrong in my analysis? Is this way of tracking a leftover from the pre-Deployment days?

The problem is that we'd need a lot more knowledge on the parts of operators in order to be able to safely do resource/replication changes while under load – causing...

In practice, we'd resort to mutating the Deployment directly through `kubectl`, which would have unforeseen consequences wrt Samson.

This is not just due to scaling, it's also when we realize we need to change the resource limits.