Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
This PR adds a new scenario, called
benchmark
. The purpose of this scenario is to setup the required infrastructure to run performance tests against a Vault cluster. In its current state, the tests are not run automatically.Note that the scenario hardcodes ubuntu/amd64. This was a choice made for expediency, as some of the packages that needed installing had to be installed from source, rather than a package manager. Ultimately, it would probably be nice to go back and remove those hardcoded choices and make the package installation a bit more flexible.
There are a few pieces to this new scenario:
benchmark
modulemetrics 8000
andk6
instances.k6
instance, surprise!metrics
instance.metrics
instance.k6
instance.restart_consul
module, for restarting Consul (surprise!) after the telemetry is added.create_metrics_security_groups
module for creating the security groups needed for opening grafana and prometheus ports.max_io
variable for passing to thetarget_ec2_instances
module. If present, this will configure fast disks.Right now this is used by:
k6-run.sh
script to run a specific k6 scenarioEventually, I think the plan is to automate all of this in CI somehow, but it’s not clear to me how the data would be automatically collected after a run. That’s a future problem though, not something that needs solving in this PR (unless there’s an easy way).
Also, note that I’m very new to Terraform and Enos both, so I’m sure this whole PR is ripe for optimization.
https://hashicorp.atlassian.net/browse/VAULT-36161
TODO only if you're a HashiCorp employee
backport/
label that matches the desired release branch. Note that in the CE repo, the latest release branch will look likebackport/x.x.x
, but older release branches will bebackport/ent/x.x.x+ent
.of a public function, even if that change is in a CE file, double check that
applying the patch for this PR to the ENT repo and running tests doesn't
break any tests. Sometimes ENT only tests rely on public functions in CE
files.
in the PR description, commit message, or branch name.
description. Also, make sure the changelog is in this PR, not in your ENT PR.