effectively disable libvirt live snapshotting

As being seen in the gate, libvirt 1.2.2 doesn't appear to actually
handle live snapshotting under any appreciable load (possibly
related to parallel operations). It isn't a 100% failure, but it's
currently being hit in a large number of runs.

Effectively turn this off by increasing the
MIN_LIBVIRT_LIVESNAPSHOT_VERSION to something that doesn't yet
exist. This can get us back to a working state, then we can decide
if live snapshotting is something that can be made to actually work
under load.

DocImpact

Related-Bug: #1334398

Change-Id: I9908b743df2093c8dd2723af89be51630eafc99f
VMware: create utility function for reconfiguring a VM

A utility method has been created that simplifies the process of
reconfiguring a VM.

Change-Id: I184e2483726e29819164175493cfd1559592358b
Make Evacuate API use Instance objects.

Replace current instance dicts and conversions to Instance Objects.
Add services arg to create_fake_instance_obj.

Change-Id: I7ddf11ce17df254a8253461e17b5c6519cb7d6fe
Related to blueprint compute-manager-objects-juno
Merge "effectively disable libvirt live snapshotting"
libvirt: test setting of CPU tuning data

The setting of the libvirt guest <cputune> data from the
flavor extra_specs quota parameter was never tested. In
fixing this omission, it was noticed that the data was
incorrectly passed around as a string instead of an int.

Change-Id: Ie8b31feddf6c546eb05ca00ead5c56bcd535dd84
libvirt: introduce separate class for cpu tune XML config

Instead of just setting attributes against the main
LibvirtConfigGuest object, have a LibvirtConfigGuestCPUTune
object. This is more flexible when we have to add support
for further cpu tuning attributes.

Blueprint: virt-driver-cpu-pinning
Change-Id: Id3667752fcbbfe3e55ee221fd2cd364d5cfb2f80
VMware: refactor get_datastore_ref_and_name

Update vm_util.get_datastore_ref_and_name to use Datastore class,
renamed it to get_datastore, remove vm_util.DSRecord along the way.

partial blueprint vmware-spawn-refactor

Change-Id: Ib3308870c09344036c4f330a48513581f5771246
Merge "Use default rpc_response_timeout in unit tests"
VMware: Fix fake raising the wrong exception in _remove_file

fake was raising exception.FileNotFound error if a file was not found.
However, an actual delete on a non-existent file raises the error
returned by vSphere, which is error_util.FileNotFoundException. This
breaks tests which exercise error paths expecting the real error to be
raised.

Fortunately this change doesn't break any existing tests. However, I'm
not sure that's a good thing.

Change-Id: I2025bffa887582eaa9e9072d0400f90ca97d1898
Merge "Add Agent object"
Merge "Object-ify xenapi driver's use of agent_build_get_by_triple()"
Merge "Deprecate and remove agent_build_get_by_triple()"
Fix update agent return agent_id with string for os-agents v3

Currently the agent update return agent_id with integer, that is
inconsistent with the response of agent create and index. It because
agent update use the agent_id that passed from url as the response.
This problem is fixed by converting the agent id as integer.

And the API sample tests provide agent_id with string type in the fake
data. This patch fix this problem for API sample files and tests.

And for back-compatibility, we should add translator for v2.1 API later.
Then this fix will be exposed after v3 API feature exposed by microversion
in the future.

DocImpact: The agent_is is changed to integer type for agents'update action.

Change-Id: Ia9c1034a325b77a2057934cc80b6eab679ff1d2b
Partial-Bug: #1333494
Fix agent_id with string type in API samples files for os-agents v2

The agent_id should be integer for agent create and index. But in
the api sample file it is string type. It's because the api sample
tests provide agent_id with string type in fake data. This patch
correct the api sample files and tests.

For agent update, it use agent_id that passed from url, make the
response use string for agent_id. We can't fix this problem for
back-compatibility. This will be fix in the future after v3 API
expose by micro-version

Change-Id: I262b4b26c94dba003e80bda2f38d2e985ef9f220
Partial-Bug: #1333494
Xen: Remove extraneous logging of type information

There doesn't appear to be any value in logging the type of vdi_rec
after its value has just been logged.  It's just adding noise to the
logs.

Change-Id: Ia5ccc634375d9a4fa4783487908cb4f91f435a68
Merge "Sync revert and finish resize on instance.uuid"
Merge "VMware: refactor get_datastore_ref_and_name"
Log when nova-conductor connection established

The current warning in wait_until_ready() is a bit of a red-herring.
When just looking at the logs, it's warning status may lead you to
believe the failure to connect to nova-conductor is fatal when really
it was retried and connected successfully.

The WARNING message on timeout is modified to clearly show that it is
retrying the connection.  A partner message is shown to inform that
the connection has been established.

Change-Id: I2040707df7caf8685c84c82ec9b8cc97cb04b47e
Merge "Fix the rest of direct uses of instance module objects"
Merge "Fix object code direct use of other object modules"