Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

[Workload]: http

Abierto
  • ¿Algo no está bien?
#154 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
58/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
go, kubernetes, nginx
Área
devops, infrastructure, networking

Línea de trabajo

Comienza localizando la carga de trabajo de red existente que usa iperf3 y su implementación de MultiVMWorkload con RoleDistribution() []RoleSpec. Usa ese patrón de servidor/cliente para definir la VM del servidor nginx, la VM del cliente hey, el Kubernetes Service y los servicios systemd. Se considera terminado cuando el tráfico HTTP sostenido y configurable produce las señales solicitadas de tasa de solicitudes, latencia, código de estado, conexiones y rendimiento.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.
Lenguaje dominante
Go
Estrellas
0
Forks
0
Sin PR fusionados en 30 d

Preparar el entorno

  • Incluye un Dockerfile o un archivo de Docker Compose
  • Sin plantilla de pull request
  • Sin guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de opdev/virtwork

Todos los issues de opdev/virtwork

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.