Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

[Workload]: http

Offen
  • Stimmt etwas nicht?
#154 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
58/100
Issue-Typ
Feature
Klarheit
Größtenteils klar
Aktivitätsstatus
Ruhig
Tech-Stack
go, kubernetes, nginx
Bereich
devops, infrastructure, networking

Rechercherichtung

Beginne damit, den bestehenden Netzwerk-Workload zu finden, der iperf3 und seine MultiVMWorkload-Implementierung mit RoleDistribution() []RoleSpec verwendet. Verwende dieses Server/Client-Muster, um die nginx-Server-VM, die hey-Client-VM, den Kubernetes Service und die systemd-Services zu definieren. Als erledigt gilt die Aufgabe, wenn anhaltender, konfigurierbarer HTTP-Datenverkehr die angeforderten Signale für Request-Rate, Latenz, Statuscode, Verbindungen und Durchsatz erzeugt.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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.
Vorherrschende Sprache
Go
Sterne
0
Forks
0
Keine gemergten PRs in 30 T.

Entwicklungsumgebung

  • Enthält ein Dockerfile oder eine Docker-Compose-Datei
  • Keine Pull-Request-Vorlage
  • Kein Beitragsleitfaden

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus opdev/virtwork

Alle Issues in opdev/virtwork

Ähnliche Issues

Weitere Issues zu Go

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.