... instead of installing Debian packages. To use this feature, the
caller has to specify an Erlang Git reference (a branch, a tag or a
plain commit hash).
This is useful now to test with Erlang 21.0 which is not released yet at
the time of this commit. In the case of Erlang 21.0, if no Git reference
is specified, it defaults to `OTP-21.0-rc2`.
The time we wait for VMs to be ready is bumped from 7 to 20 minutes
because compiling Erlang and Elixir takes time.
rabbit_ct_vm_helpers takes a look at the return value of
`erlang:system_info(system_version)` because it may contain the commit
hash of the running Erlang system (if it was built from sources). It
allows to use the same commit on the remote VMs.
[#157964874]
This greatly reduces code duplication. It also allows us to add Erlang
20.2 support easily, because it shares everything with Erlang 20.1
setup, except the package revision obviously.
The single setup template knows the relationship between a version of
Erlang and the corresponding revision of a Debian package.
The relationship between a version of Erlang and the system to use
(Debian Wheezy, Jessie or Stretch) is already recorded in a Terraform
variable. Thus now, we pass it to the template as a variable. The script
is responsible to install backports repositories and extra packages as
needed.
[#153749132]
It allows one to run a common_test testsuite on Erlang nodes running on
remote Amazon EC2 VMs. It configures Erlang distribution so that remote
nodes can communicate with each other and also commmunicate with the
commont_test master node.
rabbit_ct_broker_helpers also offers new setup and teardown steps to
work with VMs: it allows to start RabbitMQ nodes on those VMS and
possible cluster them. The configuration is unchanged compared to local
nodes. The number of RabbitMQ nodes doesn't have to match the number of
VMs: they are spread using round-robin on the available VMs.
v2: Add support to start RabbitMQ nodes spread on remote VMs.
v3: Various improvements to allow parallel executions of testcases. I.e.
several sets of VMs can be spawned in parallel without interference.
v4: Support user-specified VM names. If the name is missing, use the
unique ID generated for per-VM-set resources.
v5: Use a unique local node name when trying to ping the remote ct-peer.
While here use `rabbit_misc:random()` to create Terraform unique UI.
The previous base64-encoded string didn't make a valid node name.
Accept `$ERLANG_VERSION` environment/make variable to force the
Erlang version to use on VMs.
Add setup scripts for Erlang 19.3 and 20.1.
v6: Use Amazon S3 to upload the directories archive. Configure a VPC to
access it from the VMs.
Use `user_data` to provide the setup script. The setup script itself
is now a template.
Those changes allow to get rid of all `exec` or `file` provisioners
in the `aws_instance`. This means it can now be created using a
launch configuration which is the way to create instances via an
autoscaling group.
v7: Export hostnames, nodenames and IP addresses from Terraform state,
and generate `inetrc` in Erlang. This makes it possible to work with
a "two-step Terraform manifest". For instance, with an autoscaling
group, Terraform doesn't start instances. However, we can use a
second manifest to query the created instances.
Export `$HOME` in setup scripts. This fixes the use of `~/...` paths
and the start of the remote Erlang node.
v8: Add support to query Amazon EC2 VMs, based on tags, instead of
relying on the outputs of the manifest. This will allow us to query
VMs created with an autoscaling group for instance. This change is
based on a new query-only manifest called `vms-query`.
This new query-only manifest is used in a loop until we have enough
VMs (compared to the requested numbers) or we reach a timeout of 5
minutes.
v9: Add an autoscaling-group-based module to deploy VMs. The testsuite
is extended to use it, in addition to the `direct-vms` module.
Fix the setup scripts to handle the case where there is no
directories to upload (i.e. the archive is an empty file).
v10: Download log files from remote VMs before destroying them. This
allows further debugging if something fails.
v11: Use a per-VPC CIDR block. This resolves a possible conflict when
VMs in different VPCs gets the same private IP address: this breaks
name resolution on the local common_test node.
Use inet_db:add_host() to reconfigure name resolution, instead of
calling inet_config:init(). We still write the `inetrc` files: they
are used by sub-processes such as rabbitmqctl(8) and
rabbitmq-plugins(8).
Download each VM's common_test priv_dir before destroying the VMs.
They are useful because they contain the RabbitMQ nodes logs for
instance.
Fix several concurrency bugs around global resources accessed or
shared by several setups of rabbit_vm_helpers, in case of parallel
testing.
The upload dirs archive is now created by Erlang, not Terraform. It
allows us to create a single archive per directories set, which
saves time, I/O and CPU (for compression).
Configure an EBS root block device for each VM because the default
internal storage a `t2.micro` instance type is too small.
v12: Verify that terraform(1) is available and working before doing
anything else.
v13: Guess the Erlang application name being tested (using the value of
the `$DIALYZER_PLT` environment variable, lacking a better way). We
use it now as the instance name prefix.
Allow the caller to set the AWS EC2 region.
Allow the caller to set the files suffix. Also, we record it in the
instance and launch configuration tags. This allows the caller to
do things based on a known instance tag.
Install rsync, zip and vim-nox on VMs. They are useful when one
needs to connect to the VMs and try things.
Install Elixir on 19.3+ VMs. It's not used, but it silences a
warnings from `rabbitmq-build.mk` which calls it to initialize
`$ELIXIR_LIB_DIR`.
[#153749132]
Jean-Sébastien Pédron
Jean-Sébastien Pédron
Luke Bakken
Luke Bakken