| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
| |
as we now encourage close scrutiny of the config file.
|
| |
|
|
| |
config location suggested by Kafka's sample conf.
|
| |
|
|
|
|
|
| |
and easy to reconfigure per topic as they grow.
We already had that, but this branch cares about grouping such conf.
It also encourages topic defaults geared towards persistent data.
|
| |
|
|
|
|
|
| |
in one place. These values are critical to maintain for those,
like us, who make use of auto create topics for production data.
Also a step towards #72 and #77.
|
| |
|
|
|
|
|
| |
topics at runtime, such as splitting a stream based on some business enum.
Producers and Kafka Streams apps would otherwise need to set up an AdminClient to do that.
This reverts commit: 0681cc515fa1c505b905ef60c7d3132e8d7510af
|
| |\
| |
| | |
Enable broker JMX_PORT 5555
|
| | |
| |
| |
| |
| |
| |
| | |
Already included in #49, but here we don't add any export container to the pod.
Can be utilized by kafka-manager (#83) - just tick the JMX box when adding a cluster -
to see bytes in/out rates.
|
| |/
|
|
|
|
|
|
| |
Due to the use of config map for most of the conifg,
RollingUpdate will be surprising, while still not preventing
running pods that don't have the applied configuration.
An automation effort would be required for proper RollingUpdate behavior.
|
| |
|
