kubernetes/minikube

Generate performance metric for minikube start/stop/delete speed on different drivers

Open

#4,622 opened on Jun 27, 2019

View on GitHub
 (5 comments) (3 reactions) (0 assignees)Go (31,799 stars) (5,222 forks)batch import
area/performancehelp wantedkind/featurelifecycle/frozenpriority/backlog

Description

it would be a great thing to have a script to run on each release, that does the following:

  • measure how long minikube start, start again ,stop , delete takes on each different drivers such as, virtualbox, hyperkit, hyperv and none.

the script should generate the a dirver_performance.md file in the /docs automatically on each release and purpose a PR.

The script could run as an integration test. the same way that our e2e tests run.

Contributor guide

Tech stack
go
Domain
performancedevopstesting
Issue type
feature
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
3
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
over 1 week
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
stale
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
mostly clear
Prerequisites
Go programmingminikube internalsknowledge of virtualization driverse2e testing experience
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
40
Research direction
The issue requests a script to measure minikube start/stop/delete speed on different drivers (virtualbox, hyperkit, hyperv, none) and auto generate a driver performance.md file in /docs on each release. To begin, examine existing e2e tests in the minikube repository (e.g., integration tests under test/integration/) to understand the test harness and how they invoke minikube commands. The script should be similar to existing tests but focus on timing operations. Look at the CI configuration (e.g., in .github/workflows) to see how tests are run on different drivers. The deliverable is a script that can be integrated into the release process, potentially as a new CI job. Note that this is a complex feature that requires understanding of multiple drivers and the release pipeline.