Add an additional disk to a running VM via the vmpooler API.
````
$ curl -X POST -H X-AUTH-TOKEN:a9znth9dn01t416hrguu56ze37t790bl --url vmpooler.company.com/api/v1/vm/fq6qlpjlsskycq6/disk/8
````
````json
{
"ok": true,
"fq6qlpjlsskycq6": {
"disk": "+8mb"
}
}
````
Provisioning and attaching disks can take a moment, but once the task completes it will be reflected in a `GET /vm/<hostname>` query:
````
$ curl --url vmpooler.company.com/api/v1/vm/fq6qlpjlsskycq6
````
````json
{
"ok": true,
"fq6qlpjlsskycq6": {
"template": "debian-7-x86_64",
"lifetime": 2,
"running": 0.08,
"state": "running",
"disk": [
"+8mb"
],
"domain": "delivery.puppetlabs.net"
}
}
This commit adds the following functions:
- `add_disk`: the wrapper function to add a new disk to a VM
Usage is:
````
add_disk(vmname, disksize, datastore)
````
`vmname` is the name of the VM to add the disk to, `disksize` is the
disk size in MB, and `datastore` is the datastore on which to provision
the new disk.
`add_disk` required the addition of the following helper functions:
- `find_device`: locate a device object in vSphere
- `find_disk_controller`: find the disk controller used by a VM
- `find_disk_devices`: find the disk devices used by a VM
- `find_disk_unit_number`: find a free SCSI ID to assign to a new disk
- `find_vmdks`: find names of VMDK disks attached to a VM
This PR adds spec testing for pool 'alias' functionality introduced in
17b24d6, as well as the following previously non-existant tests:
- new tests for handling requests for a VM from a nonexistant pool
- new tests for the `POST /vm/:template` endpoint
The following pool configuration would allow a pool to be aliased in POST
requests as 'centos-6-x86_64', 'centos-6-amd64', or 'centos-6-64':
````yaml
- name: 'centos-6-x86_64'
alias: [ 'centos-6-amd64', 'centos-6-64' ]
template: 'templates/centos-6-x86_64'
folder: 'vmpooler/centos-6-x86_64'
datastore: 'instance1'
size: 5
````
The 'alias' configuration can be either a string or an array.
Note that even when requesting an alias, the pool's 'name' is returned in
the JSON response:
````
$ curl -d '{"centos-6-64":"1"}' --url vmpooler/api/v1/vm
````
````json
{
"ok": true,
"centos-6-x86_64": {
"hostname": "cuna2qeahwlzji7"
},
"domain": "company.com"
}
````
Prior to this commit, a running VM could fail a ping check and be
destroyed. This causes issues when network hiccups occur or the machine
is performing a reboot.
A VM that is in a ready state will now be destroyed when handed back or
it hits the lifetime TTL.
An SSH check was added before moving a VM from pending to ready.
However, the result of that check did not matter and move_pending would
still be called. This moves the move_pending call to within the begin
block that holds the SSH check. If the check fails, then only
fail_pending will be called.
SSH should be available before a VM is moved from the 'pending' queue to
'ready'.
`check_ssh` should probably be a function in the tradition of DRY; I'm
going to hopefully follow up this PR with a `Vmpooler::Utility` library.
As we approach an "official" v1.0.0 of the API I'd like to remove some old
nested "ok" responses. These were left in as the Beaker vmpooler
hypervisor used them, but I long-ago patched that code and I think it's
time to deprecate these.
* rename the Redis token 'timestamp' var to 'created'
* update the Redis token 'last' var when token is successfully validataed
* expose the Redis token 'last' var in GET /token route
The return values from most redis calls inform the caller of whether a
key or hash value exists. Several exists() calls can be removed in
favor of this approach.
Updated spec tests to account for a removal of exists() and ismember()
calls in API tests.
