Skip to content

Releases: mesos/kafka

v0.10.0.0

25 Jan 19:08
Compare
Choose a tag to compare

This release brings a many major new features an enhancements.

  • The scheduler now builds against 0.8.2.2, 0.9+, and 0.10+. It is HIGHLY recommended to use a version of the scheduler built against the same version of kafka that will be launched. This is due to changes over time to the kafka zookeeper layout/APIs.
  • Rolling restarts now wait for replication to catch up after restarting each broker. This can be disabled with the --noWaitForReplication flag to broker restart.
  • The mesos offer management system has been significantly refactored. On versions of mesos that support it (0.25.0+), offers to the framework will be completed suppressed when the cluster is in a "steady state". Additionally, offers that don't match a broker are rejected with a long filter duration. On clusters with large amounts of offers this should significantly decrease the CPU usage on both the mesos master and kafka-mesos scheduler.
  • Reconciliation has been improved, and the default timeout significantly increased to protect against accidentally terminating brokers on a mesos master failover.
  • A new CLI command has been added (as well as REST endpoint) to get all metrics published by a set of brokers: broker metrics

Breaking changes

While we try very hard to preserve backwards compatibility between releases, there are times that breaking changes must be made. This release introduces one, which may impact people who have built tooling around the HTTP API.

  • Methods that mutate state (broker restart, add, delete, etc) no longer accept GET requests, only POST. This is to lock down the scheduler to prevent unintended actions (eg via malicious URLs).

Note: The attached artifacts are built with JDK 1.8 for Kafka 0.9.0.1 and 0.10.1.1.

v0.9.5.1 Release

18 May 03:06
Compare
Choose a tag to compare
  • change task and executor name to the framework name
  • test case fixes, refactoring

0.9.5.0 Release

11 Mar 06:06
Compare
Choose a tag to compare

0.9.4.0 Release

30 Dec 04:24
Compare
Choose a tag to compare
  • fixed snappy native lib loading issue #158
  • Kafka_0_9_support #168
  • changed vagrant to use mesos 0.25* and marathon 0.10* versions

0.9.3.0 Release

12 Nov 13:18
Compare
Choose a tag to compare
  • broker add|update command now supports --volume option, specifying pre-reserved persistent volume id

0.9.2.0 Release

22 Sep 19:46
Compare
Choose a tag to compare
  • topic list, add update admin features through scheduler
  • assignment of partition based on attribute, provides rack awareness for partitions
  • refactored CLI & REST API to support broker and topic sub commands
  • breaking change in the API remove plural (e.g. api/brokers are now api/broker)

0.9.1.4 Release

29 Jul 14:39
Compare
Choose a tag to compare

Fixes for stats metrics not starting and being reported properly.

0.9.1.3 Release

27 Jul 17:34
Compare
Choose a tag to compare
0.9.1.3 Release Pre-release
Pre-release
  • build number for jar didn't match tag

0.9.1.2 release

22 Jul 12:23
Compare
Choose a tag to compare
0.9.1.2 release Pre-release
Pre-release
  • fixes for multiple schedulers' state
  • scheduler bind address update

0.9.1.1 release

13 Jul 02:51
Compare
Choose a tag to compare
0.9.1.1 release Pre-release
Pre-release
  • Changed default failover for broker from delay of 1 minute and max-delay of 10 minutes. This failover is related to the broker failing and being relaunched on the same slave node. At some point this should give up. Future version will accept a callback from an outside plug-in for monitoring issues such as disk space. Often other schedulers might be part of the general allocation so a time window of trying for 1 minute with a progression to not exceed 10 minutes (based on maxTries which is still defaulted to 2). #77 created to add more scheduler ability to deal with infrastructure acked problems programmatically and more metrics.
  • Broker Placement Stickiness - For both failover and manual restarts you often want a window of time that the scheduler will wait for the same resources it had before to become available. When this exceeds the time set the scheduler will then seek resources from another machine. A manual stop can be issued before or during the time period for maintenance tasks via the CLI or REST API.