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

[Workload]: http

オープン
  • 何か問題がありますか？
#154 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

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

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
58/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
静か
技術スタック
go, kubernetes, nginx
領域
devops, infrastructure, networking

調査の方向性

まず、iperf3 と RoleDistribution() []RoleSpec を備えた MultiVMWorkload の実装を使用している既存のネットワークワークロードを見つけます。そのサーバー/クライアントパターンを使用して、nginx サーバー VM、hey クライアント VM、Kubernetes Service、および systemd サービスを定義します。設定可能な HTTP トラフィックを継続的に生成し、要求されたリクエストレート、レイテンシ、ステータスコード、接続数、スループットのシグナルが得られれば完了です。

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

説明

good first issue priority/backlog size/L triage/accepted workload-request workload/tier-1
Workload Name

http

Workload Description

Web traffic generation workload using nginx as a server and hey (or wrk2) as a client. Produces sustained L7 HTTP signals: request rates, latency distributions (p50/p95/p99), HTTP status codes, connection counts, and throughput (requests/sec, bytes/sec).

This is the single biggest signal gap in virtwork today. Every monitoring/APM partner (Dynatrace, Datadog, New Relic, Instana), service mesh partner (Istio, Linkerd integrations), WAF partner, and load balancer partner needs application-level HTTP traffic — not just infrastructure metrics. The current workloads generate CPU, memory, disk, and network pressure, but no L7 request/response signals.

Tooling and Packages

Server VM:

  • Tool: nginx
  • RPM packages: nginx
  • systemd service: nginx.service (default or custom config serving static content + /status endpoint)
  • Exposes port 80 (HTTP) via Kubernetes Service

Client VM:

  • Tool: hey (HTTP load generator) or wrk2 (constant-throughput HTTP benchmark)
  • Installation: hey is a single Go binary; wrk2 available via EPEL or built from source
  • systemd service command: hey -z 0 -c 50 -q 100 http://<server-service>:80/ (sustained 100 RPS with 50 concurrent connections)
  • Configurable parameters: concurrency (-c), target RPS (-q), request path, HTTP method
VM Count Model

VM pair - server and client (like network)

Required Resources
  • Kubernetes Service (for inter-VM communication)
  • Persistent storage (DataVolume)
  • Kubernetes Secret (for credentials or config)
  • Additional CPU/memory beyond defaults
  • GPU or special device passthrough
Cloud-Init Details

Server VM:

packages:
  - nginx
runcmd:
  - systemctl enable --now nginx

Client VM:

write_files:
  - path: /etc/systemd/system/virtwork-http.service
    content: |
      [Unit]
      Description=Virtwork HTTP load generator
      After=network-online.target
      Wants=network-online.target
      [Service]
      Type=simple
      ExecStart=/usr/local/bin/hey -z 0 -c 50 -q 100 http://<server-service>:80/
      Restart=always
      RestartSec=5
      [Install]
      WantedBy=multi-user.target
runcmd:
  - curl -Lo /usr/local/bin/hey https://hey-release.s3.us-east-2.amazonaws.com/hey_linux_amd64
  - chmod +x /usr/local/bin/hey
  - systemctl enable --now virtwork-http.service
Use Case
  • APM/Monitoring partners: Need HTTP request metrics (rate, latency, errors) to validate their agents report accurate application performance data from VMs on OpenShift.
  • Service mesh partners: Need L7 traffic flowing between VMs to validate traffic management, mTLS, and observability features work correctly with KubeVirt VM-to-VM communication.
  • WAF/Security partners: Need HTTP traffic to validate web application firewall rules and threat detection against real request patterns from VMs.
  • Load balancer partners: Need sustained HTTP traffic to validate load balancing, health checks, and traffic distribution across VM backends.
Additional Context
  • Follows the same multi-VM pattern as the existing network (iperf3) workload — implements MultiVMWorkload with RoleDistribution() []RoleSpec for server/client roles.
  • hey is preferred over wrk2 for initial implementation: single static binary, no build dependencies, well-maintained. wrk2 could be offered as an alternative profile.
  • The server VM's nginx /status endpoint (stub_status module) provides connection-level metrics that monitoring partners can scrape directly.
  • Consider exposing configurable parameters: concurrency, target RPS, request payload size, HTTP method (GET/POST), request path.
主要言語
Go
スター
0
フォーク
0
30日以内にマージされた PR はありません

環境構築

  • Dockerfile または Docker Compose ファイルあり
  • プルリクエストのテンプレートなし
  • コントリビューションガイドなし

はじめの一歩

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

opdev/virtwork のほかの issue

opdev/virtwork の issue をすべて見る

似ている issue

Go の issue をもっと見る

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

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