Normally when a VM is failing the vm_ready? check, it is moved to the completed queue which deletes it.
In a pooled config a new VM will be retried. For ondemand, we would also recreate the task to trigger
the creation of a new VMs. There was a bug where an ondemand request would be retried infinitely when
vm_ready? would always fail. We would never check the status of the request if it was deleted via the
API or if it was detected as failed because it is expired (over the ondemand_request_ttl limit)
there was one API that was falling back on v1 and was returning a domain key.
in order to make it consistent with the changes in v2, the domain is not returned
anymore, and the fqdn is returned if it is available
the vm_ready methods should be implemented per provider and checking in the api
creates issues since provider code is not available. Removing this for the V2 api
The syntax for pipelined has changed and the old syntax will be removed in v5.0.0
Fixing the syntax now since the block syntax has been supported for a while now.
Before this change if an extra config file had new keys they would get
merged to the main config but if it contained an existing key, like
'providers' it would overwrite the original config.
Adding a library 'deep_merge' to do a more natural merge, where existing keys
get sub-elements added together and arrays are combined like for the
pool configuration.
Adding spec tests around EXTRA_CONFIG as they were missing, by adding
and testing two new extra_config.yaml fixture files
This method should be called only once, when the VM is moved to a running state
which is when the data for the user (if using tokens) is available. In vmpooler
base provider it is a noop method, but the various providers can implement it
to tag or label a running VM with the name of the user who checked it out
