* Add redis to our travis runs * De-mockistify v1/token specs; use real redis. Open questions: - Do we need to do better cleanup here? - Should we be using a separate database to prevent clobbering other local db's? * Remove mockist tests from main suite. * (MAINT) gitignore some common files * (maint) Clean up some of the /vm/ tests * (maint) Convert specs for /vm/template * (maint) Clean up, reorganize specs * (maint) Move extracted spec helper methods to spec_helper * (maint) rename create_vm -> create_ready_vm * (WIP) add partially-converted /vm/hostname specs * (maint) clean up vm_spec * (WIP) notes for next steps * (maint) Define :config in token tests Miscellaneous whitespace cleanup. * (maint) Lift #redis definition into spec helper library * (maint) drop unneeded clear_pool helper Given the way we're flushing redis (which seems super performant), we don't need to clear pools any more at the beginning of tests. * (maint) Drop clear_pool from vm/template specs * (maint) Update vm/hostname tag and lifetime specs * (maint) Convert vm deletion specs * (maint) Convert specs for vm snapshot operations * (maint) Drop now-obsolete v1_spec.rb * (maint) cosmetic cleanup in spec helper * (maint) begin de-mockistifying api_spec.rb * (maint) repair incorrect test The mockist version of the test allows redis' scard to return nil, which it does not actually do in real life. Verified the behavior in the code via a debugger. Fixed the test. * (maint) finish converting dashboard specs * (maint) rename api_spec to dashboard_spec * (maint) Don't clobber default redis database when running specs |
||
|---|---|---|
| lib | ||
| scripts | ||
| spec | ||
| .gitignore | ||
| .travis.yml | ||
| API.md | ||
| Gemfile | ||
| LICENSE | ||
| Rakefile | ||
| README.md | ||
| vmpooler | ||
| vmpooler.yaml.example | ||
vmpooler
vmpooler provides configurable 'pools' of instantly-available (running) virtual machines.
Usage
At Puppet Labs we run acceptance tests on thousands of disposable VMs every day. Dynamic cloning of VM templates initially worked fine for this, but added several seconds to each test run and was unable to account for failed clone tasks. By pushing these operations to a backend service, we were able to both speed up tests and eliminate test failures due to underlying infrastructure failures.
Installation
Prerequisites
vmpooler requires the following Ruby gems be installed:
It also requires that a Redis server exists somewhere, as this is the datastore used for vmpooler's inventory and queueing services.
Configuration
The following YAML configuration sets up two pools, debian-7-i386 and debian-7-x86_64, which contain 5 running VMs each:
---
:vsphere:
server: 'vsphere.company.com'
username: 'vmpooler'
password: 'swimsw1msw!m'
:redis:
server: 'redis.company.com'
:config:
logfile: '/var/log/vmpooler.log'
:pools:
- name: 'debian-7-i386'
template: 'Templates/debian-7-i386'
folder: 'Pooled VMs/debian-7-i386'
pool: 'Pooled VMs/debian-7-i386'
datastore: 'vmstorage'
size: 5
- name: 'debian-7-x86_64'
template: 'Templates/debian-7-x86_64'
folder: 'Pooled VMs/debian-7-x86_64'
pool: 'Pooled VMs/debian-7-x86_64'
datastore: 'vmstorage'
size: 5
See the provided YAML configuration example, vmpooler.yaml.example, for additional configuration options and parameters.
Template set-up
Template set-up is left as an exercise to the reader. Somehow, either via PXE, embedded bootstrap scripts, or some other method -- clones of VM templates need to be able to set their hostname, register themselves in your DNS, and be resolvable by the vmpooler application after completing the clone task and booting up.
API and Dashboard
vmpooler provides an API and web front-end (dashboard) on port :4567. See the provided YAML configuration example, vmpooler.yaml.example, to specify an alternative port to listen on.
API
vmpooler provides a REST API for VM management. See the API documentation for more information.
Dashboard
A dashboard is provided to offer real-time statistics and historical graphs. It looks like this:
Graphite is required for historical data retrieval. See the provided YAML configuration example, vmpooler.yaml.example, for details.
Command-line Utility
The vmpooler_client.py CLI utility provides easy access to the vmpooler service. The tool is cross-platform and written in Python.
Build status
License
vmpooler is distributed under the Apache License, Version 2.0. See the LICENSE file for more details.


