Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

[Workload]: http

Đang mở
#154 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
58/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Ít trao đổi
Công nghệ
go, kubernetes, nginx

Hướng nghiên cứu

Bắt đầu bằng cách tìm workload mạng hiện có sử dụng iperf3 và phần triển khai MultiVMWorkload với RoleDistribution() []RoleSpec. Sử dụng mẫu server/client đó để định nghĩa VM server nginx, VM client hey, Kubernetes Service và các systemd service. Hoàn thành khi lưu lượng HTTP liên tục, có thể cấu hình tạo ra các tín hiệu được yêu cầu về tốc độ yêu cầu, độ trễ, mã trạng thái, kết nối và thông lượng.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.
Ngôn ngữ chính
Go
Star
0
Fork
0
Chỉ số merge pull request
Không có pull request nào được merge trong 30 ngày

Chuẩn bị môi trường

  • Có Dockerfile hoặc tệp Docker Compose
  • Không có mẫu pull request
  • Không có hướng dẫn đóng góp

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của opdev/virtwork

Tất cả issue của opdev/virtwork

Issue tương tự

Thêm issue về Go

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.