Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Figure out a way to test against constantly cycling Kafka cluster

オープン
#1,311 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
25/100
issue の種類
機能追加
明瞭さ
説明が足りない
活発さ
停滞
技術スタック
docker, kafka, python, shell

調査の方向性

ファイル、テスト、CI のエントリポイントは指定されていません。まず issue #1310 と #1306 を確認し、次に既存の Kafka テストとリリースのセットアップを調べてから、ブローカーの強制停止、リーダーシップの変更、再起動を繰り返し実行する方法を決定してください。繰り返し実行可能なテストで、拡張されたリリース検証の実行中にこれらの障害を発生させられれば完了です。

索引モデルが issue の本文から書いたものです。

説明

test coverage

After recently hitting both #1310 and #1306 in production, I want to find a way to test kafka-python against a constantly cycling Kafka cluster.

Those problems are both race conditions that prevent kafka-python from successfully recovering when a broker is restarted. Unfortunately, unit tests rarely catch this, so I want to create a Kafka cluster that is constantly killing a broker, moving partition leadership to another broker, then restarting the killed broker, etc.

Ideally I'd run every new release for a couple of days against this before deploying it.

I can cobble something together with shell scripts and Docker, but wondered if anyone had better ideas?

I am not aware of a CI service that currently supports this model of running N number of cycles of cluster failures.

主要言語
Python
スター
5.9k
フォーク
1.5k
PR マージ指標
30日以内にマージされた PR はありません

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

dpkp/kafka-python のほかの issue

dpkp/kafka-python の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。