Unbundle iptools, use iptools 0.6.1
When jobs are in the queue and no slots exists, immediately add a node
Merge pull request #260 from datacratic/quick_add_node_when_none

When jobs are in the queue and no slots exists, immediately add a node
FIX: only clean-up placement groups in supported regions

Trying to use *any* AWS API call related to placement groups in regions
that do not support placement groups fails with an UnsupportedOperation
error (including DescribePlacementGroup). Updated
Cluster.terminate_cluster to check whether the cluster's region supports
placement groups first before attempting to fetch and clean-up the
cluster's placement group (if any).

closes gh-261
ebsimage: fetch root device from instance metadata

Fetch the real root device from instance metadata server rather than
assuming '/dev/sda1' which is what the root device *should* be but isn't
always the case unfortunately

closes gh-258
minor import cleanup

Imports should be in order 1) stdlib 2) 3rd party 3) internal
shell: auto-import pyasn1 and iptools modules
Merge branch 'unbundle-iptools' into develop

closes gh-246
node: fix Node.root_device_name for misconfigured AMIs

Apparently EC2 AMIs are allowed to specify a root device name that is
*not* in the image's block device mapping and amazingly they're not only
allowed to be created but they also *work* by some magic in the EC2
backend. Any instance started with a misconfigured AMI also reports the
same root device name that is *not* in the instance's block device
mapping. This was causing the real root device to be recognized as an
external EBS volume when calling Node.detach_external_volumes().

For example: CentOS 6.4 (Marketplace AMI) ami-bf5021d6

This patch to the Node.root_device_name attribute first checks that the
root device name returned by EC2 is actually in the instance's block
device mapping before returning. If it's not it attempts to fetch the
*real* root device from the instance's local metadata server assuming
the instance is running and SSH is up. If SSH isnt up the code looks for
common mistakes like /dev/sda1->/dev/sda and 'assumes' a root device if
possible.

closes gh-238
awsutils: use 3 decimal places in spot history prices

closes gh-237
ebsimage: only wait for snapshot if root device is in bmap

Turns out the internal metadata server is no more accurate about the
real root device than the EC2 API in the case that the AMI has an
incorrect root device name that doesnt exist in the block device.
Updated EBSImageCreator to skip showing root device snapshot progress
and simply wait on the AMI to become 'available' if the root device
listed by the EC2 API is not in the block device mapping.

closes gh-238 (for real this time ;)
node: fix root_device_name again for misconfigured AMIs

Do not use instance metadata server to fetch root device name - it
returns the same thing as the EC2 API even in the case that the root
device name is not in the block device mapping.

Updated Node.root_device_name attribute to simply handle the case that
/dev/sda1 is listed as the root device name yet only /dev/sda exists in
the block device mapping as is the case for CentOS 6.x marketplace AMIs.
All other cases simply report a warning that the root device name is
missing from the instance's block device mapping.

closes gh-238
node: fix false positive in root_device_name attr

Do not check for missing root device name issue if the block device
mapping does not contain any entries which is always the case for
'pending' instances.
awsutils: use /dev/xvd[a-z][a-z] for ephemeral drives

Better fix for gh-213. Use /dev/xvd[a-z][a-z] for ephemeral drives in the
runtime mapping in EasyEC2.request_instances. This avoids collision
with potential EBS volume mappings (ie /dev/sd[a-z]). This also avoids
needing to special-case the ephemeral drive naming scheme for
hs1.8xlarge because /dev/xvd[a-z][a-z] doesn't cause an
Internal.ServerError when launching hs1.8xlarge instances and seems to
work for all other instance types (tested on t1.micro, m1.small,
m1.xlarge, hs1.8xlarge).

Removed device_fmt kwarg from EasyEC2.create_block_device_map. This
function now handles the ephemeral device naming scheme internally.
balancer: fix logic in SGEStats._count_tasks

SGEStats._count_tasks in some situations would not parse the 'tasks'
output from qstat correctly given that it expected either a list of
single task ids or a single task range specification like '1-10:1'.
Updated _count_tasks to support task lists that contain both single task
ids and task id range specifications.

closes gh-199
balancer: remove estimated time to completion calcs

These calculations have no impact on the code's decision making and
looking closely I dont believe this information is all that accurate,
useful, or clear to anyone.
balancer: use # of nodes for max_nodes check (not exec hosts)
balancer: remove bounds on interval and wait_time

Allow any (positive) value for interval and wait_time.
balancer: require positive ints for numeric options
balancer: replace 'qlen > ts' condition in _eval_add_node

SGELoadBalancer._eval_add_node now does the following when it's checking
whether or not to add nodes:

1. Check if there are 'qw' jobs - if not return immediately
2. If total slots available is 0 then automatically set need_to_add to 1
(as done previously)
3. If there are more qw slots requested than there are available slots
in the cluster then check if the oldest job is older than max_wait and
if so calculate how many nodes to add.

The biggest change here is the condition for #3. Previously the
condition was:

    qlen > ts

The 'qlen' variable in the previous condition was the number of slots
requested by the queued and waiting (qw) jobs. The fact that there are
qw jobs at all *usually* indicates that all slots are taken - otherwise
they would be in a 'r' state. So essentially the 'qlen > ts' check
required all slots to be taken AND the number of slots requested by
queued jobs to be greater than the total slots in the cluster before
checking whether to add nodes which is not the desired behavior.

Instead of using 'qlen > ts' the code now uses 'qw_slots > avail_slots'
which means '# of slots requested by qw jobs is greater than the number
of *available* slots in the cluster'. This check would not be necessary
at all if it weren't for the fact that SGE's scheduler processes job on
an interval and it's possible that some jobs are 'qw' even though slots
are available due to the scheduler not yet going through another
iteration.

This patch implements the suggestion by @dmachi in gh-69 concerning
skipping the 'qlen > ts' check altogether. The only exception is the
fact that 'qlen > ts' has been replaced by 'qw_slots > avail_slots' for
the reasons mentioned above.