Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

[Workload]: http

Ouverte
  • Quelque chose ne va pas ?
#154 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
58/100
Type d'issue
Fonctionnalité
Clarté
Plutôt claire
Activité
Calme
Stack technique
go, kubernetes, nginx
Domaine
devops, infrastructure, networking

Piste de recherche

Commencez par localiser la charge de travail réseau existante qui utilise iperf3 et son implémentation de MultiVMWorkload avec RoleDistribution() []RoleSpec. Utilisez ce modèle serveur/client pour définir la VM serveur nginx, la VM cliente hey, le Kubernetes Service et les services systemd. Le travail est considéré comme terminé lorsque du trafic HTTP soutenu et configurable produit les signaux demandés de débit de requêtes, de latence, de code d’état, de connexions et de débit réseau.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.
Langage dominant
Go
Étoiles
0
Forks
0
Aucune PR mergée en 30 j

Préparer son environnement

  • Fournit un Dockerfile ou un fichier Docker Compose
  • Aucun modèle de pull request
  • Aucun guide de contribution

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de opdev/virtwork

Toutes les issues de opdev/virtwork

Issues similaires

Plus d'issues Go

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.