* e2e: create a v3/ set of packages for creating Nomad e2e tests
This PR creates an experimental set of packages under `e2e/v3/` for crafting
Nomad e2e tests. Unlike previous generations, this is an attempt at providing
a way to create tests in a declarative (ish) pattern, with a focus on being
easy to use, easy to cleanup, and easy to debug.
@shoenig is just trying this out to see how it goes.
Lots of features need to be implemented.
Many more docs need to be written.
Breaking changes are to be expected.
There are known and unknown bugs.
No warranty.
Quick run of `example` with verbose logging.
```shell
➜ NOMAD_E2E_VERBOSE=1 go test -v
=== RUN TestExample
=== RUN TestExample/testSleep
util3.go:25: register (service) job: "sleep-809"
util3.go:25: checking eval: 9f0ae04d-7259-9333-3763-44d0592d03a1, status: pending
util3.go:25: checking eval: 9f0ae04d-7259-9333-3763-44d0592d03a1, status: complete
util3.go:25: checking deployment: a85ad2f8-269c-6620-d390-8eac7a9c397d, status: running
util3.go:25: checking deployment: a85ad2f8-269c-6620-d390-8eac7a9c397d, status: running
util3.go:25: checking deployment: a85ad2f8-269c-6620-d390-8eac7a9c397d, status: running
util3.go:25: checking deployment: a85ad2f8-269c-6620-d390-8eac7a9c397d, status: running
util3.go:25: checking deployment: a85ad2f8-269c-6620-d390-8eac7a9c397d, status: successful
util3.go:25: deployment a85ad2f8-269c-6620-d390-8eac7a9c397d was a success
util3.go:25: deregister job "sleep-809"
util3.go:25: system gc
=== RUN TestExample/testNamespace
util3.go:25: apply namespace "example-291"
util3.go:25: register (service) job: "sleep-967"
util3.go:25: checking eval: a2a2303a-adf1-2621-042e-a9654292e569, status: pending
util3.go:25: checking eval: a2a2303a-adf1-2621-042e-a9654292e569, status: complete
util3.go:25: checking deployment: 3395e9a8-3ffc-8990-d5b8-cc0ce311f302, status: running
util3.go:25: checking deployment: 3395e9a8-3ffc-8990-d5b8-cc0ce311f302, status: running
util3.go:25: checking deployment: 3395e9a8-3ffc-8990-d5b8-cc0ce311f302, status: running
util3.go:25: checking deployment: 3395e9a8-3ffc-8990-d5b8-cc0ce311f302, status: successful
util3.go:25: deployment 3395e9a8-3ffc-8990-d5b8-cc0ce311f302 was a success
util3.go:25: deregister job "sleep-967"
util3.go:25: system gc
util3.go:25: cleanup namespace "example-291"
=== RUN TestExample/testEnv
util3.go:25: register (batch) job: "env-582"
util3.go:25: checking eval: 600f3bce-ea17-6d13-9d20-9d9eb2a784f7, status: pending
util3.go:25: checking eval: 600f3bce-ea17-6d13-9d20-9d9eb2a784f7, status: complete
util3.go:25: deregister job "env-582"
util3.go:25: system gc
--- PASS: TestExample (10.08s)
--- PASS: TestExample/testSleep (5.02s)
--- PASS: TestExample/testNamespace (4.02s)
--- PASS: TestExample/testEnv (1.03s)
PASS
ok github.com/hashicorp/nomad/e2e/example 10.079s
```
* cluster3: use filter for kernel.name instead of filtering manually
End to End Tests
This package contains integration tests. Unlike tests alongside Nomad code,
these tests expect there to already be a functional Nomad cluster accessible
(either on localhost or via the NOMAD_ADDR env var).
See framework/doc.go for how to write tests.
The NOMAD_E2E=1 environment variable must be set for these tests to run.
Provisioning Test Infrastructure on AWS
The terraform/ folder has provisioning code to spin up a Nomad cluster on
AWS. You'll need both Terraform and AWS credentials to setup AWS instances on
which e2e tests will run. See the
README
for details. The number of servers and clients is configurable, as is the
specific build of Nomad to deploy and the configuration file for each client
and server.
Provisioning Local Clusters
To run tests against a local cluster, you'll need to make sure the following environment variables are set:
NOMAD_ADDRshould point to one of the Nomad serversCONSUL_HTTP_ADDRshould point to one of the Consul serversNOMAD_E2E=1
TODO: the scripts in ./bin currently work only with Terraform, it would be
nice for us to have a way to deploy Nomad to Vagrant or local clusters.
Running
After completing the provisioning step above, you can set the client
environment for NOMAD_ADDR and run the tests as shown below:
# from the ./e2e/terraform directory, set your client environment
# if you haven't already
$(terraform output environment)
cd ..
go test -v ./...
If you want to run a specific suite, you can specify the -suite flag as
shown below. Only the suite with a matching Framework.TestSuite.Component
will be run, and all others will be skipped.
go test -v -suite=Consul .
If you want to run a specific test, you'll need to regex-escape some of the test's name so that the test runner doesn't skip over framework struct method names in the full name of the tests:
go test -v . -run 'TestE2E/Consul/\*consul\.ScriptChecksE2ETest/TestGroup'
^ ^ ^ ^
| | | |
Component | | Test func
| |
Go Package Struct
We're also in the process of migrating to "stdlib-style" tests that
use the standard go testing package without a notion of "suite". You
can run these with -run regexes the same way you would any other go
test:
go test -v . -run TestExample/TestExample_Simple
I Want To...
...SSH Into One Of The Test Machines
You can use the Terraform output to find the IP address. The keys will
in the ./terraform/keys/ directory.
ssh -i keys/nomad-e2e-*.pem ubuntu@${EC2_IP_ADDR}
Run terraform output for IP addresses and details.
...Deploy a Cluster of Mixed Nomad Versions
The variables.tf file describes the nomad_version, and
nomad_local_binary variables that can be used for most circumstances. But if
you want to deploy mixed Nomad versions, you can provide a list of versions in
your terraform.tfvars file.
For example, if you want to provision 3 servers all using Nomad 0.12.1, and 2 Linux clients using 0.12.1 and 0.12.2, you can use the following variables:
# will be used for servers
nomad_version = "0.12.1"
# will override the nomad_version for Linux clients
nomad_version_client_linux = [
"0.12.1",
"0.12.2"
]
...Deploy Custom Configuration Files
Set the profile field to "custom" and put the configuration files in
./terraform/config/custom/ as described in the
README.
...Deploy More Than 4 Linux Clients
Use the "custom" profile as described above.
...Change the Nomad Version After Provisioning
You can update the nomad_version variable, or simply rebuild the binary you
have at the nomad_local_binary path so that Terraform picks up the
changes. Then run terraform plan/terraform apply again. This will update
Nomad in place, making the minimum amount of changes necessary.