-
Notifications
You must be signed in to change notification settings - Fork 6
Pre Provisioned Hosts & Cluster Provisioning
One of the key goals of the Multi-Arch CI Libraries is providing users with the flexibility to be able to request the hosts you need in order to complete your testing needs.
A pre-provisioned host is one that is ready to use for your testing out of the box. This may or not be pre-connected to your Jenkins master. Depending on the connection protocol, it still may be necessary to run cinch to connect to this host. If your testing strategy currently relies on pre-provisioned hosts, you can override specific parameters in TargetHost to run your tests on it.
It is assumed that this can be connected to via SSH using the same credentials as a host provisioned from Beaker.
The first step to working with a preprovisioned host is to get and new TargetHost and override three key parameters: hostname
, arch
, and provisioner
.
def targetHost = MAQEAPI.v1.newTargetHost()
targetHost.hostname = 'examplehost.domain.com'
targetHost.arch = 'ppc64le'
targetHost.provisioner = 'NOOP'
The hostname
parameter is the name of the target host that the the provisioner will attempt to connect to. The arch
tells the provisioner which flavor of repositories can be installed on the host since repositories and packages vary by arch. Finally, the provisioner
parameter specifies which provisioner should create the resource. In this case, since the host is pre-provisioned, the NOOP
provisioner is specified so that the resource provisioning and teardown steps are skipped.
While not currently supported by the Multi-Arch CI Libraries, we are targeting support for cluster provisioning in the 2.x line of releases. One of the main goals of the next version of the provisioning libraries is to support the provisioning of containers and groups of hosts that will be used by a single test. Our strategy for doing this will be to produce an inventory file including all of the hosts organized in groups to be consumed by the test. This should lend itself naturally for ansible playbook tests, and should be hopefully easy enough to parse and consume for script tests.