Fixes snapshot instance failure on libvirt.

Fixed the failure during snapshotting instance (on libvirt) due to incorrect
attribute access.

Fixes LP: #1075556

Change-Id: I079467d38aef5071488084f9bfa080a2a5af2609
Fixed HyperV to get disk stats of instances drive

It fixes bug 1077922

The current version of the HyperV Compute driver was returning the disk stats about the C: drive always.

This patch makes HyperV driver extract the current drive from the flag 'instances_path'.

In order to optimize the procedure, the disk stats extraction is also unified in one method.

Change-Id: I4920cf2cc07d0f514c0358144b7bceb15d439a63
Adds a conf option for custom configdrive mkisofs

In order to support ConfigDrive on Hyper-V an option for supporting
a customizable mkisofs / genisoimage is needed, including optional
path.

The option "mkisofs_cmd" deafult to "genisoimage" to preserve
backwards compatibility

Change-Id: I89167bf77bddae9a0f989874ad0a972d7898a903
Remove unused volume exceptions

part of bp delete-nova-volume

Change-Id: I1285528ef0c2aff0f3dfea9faf2b28c55eb10a51
Added bare-metal host manager.

Part 6 of 6: blueprint general-bare-metal-provisioning-framework.

The bare-metal host manager is used when multiple bare-metal
instances are created by one request. The bare-metal host manager
detects if a nova-compute is for VM or bare-metal.
For VM instance provisioning, it simply calls the original host_manager.
For bare-metal instance provisioning, BaremetalNodeState is used
to manage bare-metal node's resources when an instance is provisioned
to a bare-metal node.

Change-Id: Ib207f495493db99a4a6cd1ac0044662fb7397322
Co-authored-by: Mikyung Kang <mkkang@isi.edu>
Co-authored-by: David Kang <dkang@isi.edu>
Co-authored-by: Ken Igarashi <igarashik@nttdocomo.co.jp>
Co-authored-by: Arata Notsu <notsu@virtualtech.jp>
Fixes usage of migrate_instance_start

Because migrate_instance_start is used to remove floating ips on the source
compute node, we need send the RPC to the source compute node instead of
the dest compute node.

Fixes bug 1078207

Change-Id: Ie993548944268e1ab3af0b89e74e1b54d8137802
Added separate bare-metal MySQL DB.

Part 2 of 6: blueprint general-bare-metal-provisioning-framework

In baremetal provisioning, one nova-compute manages multiple bare-metal
machines. A bare-metal machine does not run openstack at all.
Previously, bare-metal provisioning used text files to store information
of bare-metal machines. In this patch, a MySQL database is used to store
the information. We target only MySQL database. The DB is designed to
support PXE/non-PXE booting methods, heterogeneous hypervisor types, and
architectures. Using a MySQL database makes maintenance and upgrades
easier than using text files. The DB for bare-metal machines is
implemented as a separate DB from the main Nova DB. The DB can be on any
machines/places. The location of the DB and its server needs to be
specified as a flag in the nova.conf file (as in the case of glance).
There are a couple of reasons for this approach. First, the information
needed for bare-metal machines is different from that for non-bare-metal
machines. With a separate database for bare-metal machines, the database
can be customized without affecting the main Nova DB. Second, fault
tolerance can be embedded in nova-compute. Since one nova-compute
manages multiple bare-metal machines, fault tolerance of a nova-compute
node is very important. With a separate DB for bare-metal machines,
fault-tolerance can be achieved independently from the main Nova DB.
Replication of the bare-metal DB and implementation of fault-tolerance
are not part of this patch. The implementation models nova and its DB as
much as possible. The bare-metal driver must be upgraded to use this DB.

Change-Id: I7b7ba1903a672a50c567f95fc6554d119463b0c5
Co-authored-by: Mikyung Kang <mkkang@isi.edu>
Co-authored-by: David Kang <dkang@isi.edu>
Co-authored-by: Ken Igarashi <igarashik@nttdocomo.co.jp>
Co-authored-by: Arata Notsu <notsu@virtualtech.jp>
Adds REST API support for Fixed IPs

This adds an extension that provides a REST API for getting information
about a fixed ip, reserving a fixed ip and unreserving a fixed ip. The
interface is accessed via

/v2/{tenant_id}/os-fixed-ips/<ip_address> # GET ip info
/v2/{tenant_id}/os-fixed-ips/<ip_address>/action # POST reserve/unreserve ip

This forms part of the work to provide APIs for functionality currently
implemented by nova-manage that needs direct db access so nova-manage
can eventually be removed

Adds db function fixed_ip_get_by_address_detailed in order to optimise being able
to get the instance and network information for a fixed ip at the same
time as the rest of the fixed ip information

Change-Id: I92edf4e6b74b14bb9c49d5bc0c79e40d3a496bc5
Implements: blueprint apis-for-nova-manage
DocImpact
Sync latest code from oslo-incubator.

Change-Id: I463a6d934d17f3374763472cee7291234238c50d
Check instance_type in compute capability filter

Instance type is guaranteed to exist and not be None or empty dict
as a quite a while ago, although it used to be that prep_resize
didn't have it.

Remove the checking for instance_type.

Change-Id: I391615114bd9d9359eeb0b2b3642dcec86a8285e
Signed-off-by: Yunhong, Jiang <yunhong.jiang@intel.com>
Remove gen_uuid()

Removed gen_uuid and uuid related unittests
Replaced utils.gen_uuid() with uuid.uuid4()

Change-Id: I3020a0d67525eb73cfb8873d2570c93e2022bb76
update nova.conf.sample.

created by using generate_sample.sh.

Change-Id: I0b5a20b8a77d5d87bb0f8497f74a19eb5bbd2d06
Merge "Remove gen_uuid()"
Make sure instance data is always refreshed

Fixes bug 1078793

When updating an instance's instance_type_id, the 'instance_type' joined
to the instance is not updated.  This updates that.  A DB API test is added
that failed before and passes now.

Also: Some cases of passing stale instance data within resize_instance()
and finish_resize() were found and addressed.

Change-Id: If335cc286a71597d3100425080e51c75aeec7a50
Add module for loading specific classes

This adds nova/loadables.py which contains code that is to be shared by
host and cell scheduling filtering and weighing.

Most of this code originated from nova/scheduler/filters/__init__.py
(which was copied from nova/api extension loading).

This makes it more generic so that it can be shared.  Note that this
functionality is quite different than the generic plugin manager that
exists in openstack-common.  That code could not be used here without
some significant changes.  It also seems pretty overkill for the
functionality required by scheduling filtering and weighing.

Change-Id: I1b217dc2bc2d1dc2235c8251318d06b46597e8f4
Refactor scheduling filters

This changes the scheduling filters to use the code in nova/loadables.py
to locate filtering classes.  This also creates some base functionality
in nova/filters.py to be used by both the host scheduler and the cells
scheduler.

The scheduler_available_filters default has changed to
'nova.scheduler.filters.all_filters' which is better named compared to
the old setting of 'standard_filters'.  The old method is still
supported for those that have put it explicitly in their configs, but
it's marked as deprecated.

DocImpact

Change-Id: I84fdeafdba0275ab4b25f8857563bd7b1494bb69
Refactor scheduling weights.

This makes scheduling weights more plugin friendly and creates shared
code that can be used by the host scheduler as well as the future cells
scheduler.  Weighing classes can now be specified much like you can
specify scheduling host filters.

The new weights code reverses the old behavior where lower weights win.
Higher weights are now the winners.

The least_cost module and configs have been deprecated, but are still
supported for backwards compatibility.  The code has moved to
nova.scheduler.weights.least_cost and been modified to work with the new
loadable-class code.  If any of the least_cost related config options are
specified, this least_cost weigher will be used.

For those not overriding the default least_cost config values, the new
RamWeigher class will be used.  The default behavior of the RamWeigher
class is the same default behavior as the old least_cost module.

The new weights code introduces a new config option
'scheduler_weight_classes' which is used to specify which weigher classes
to use.  The default is 'all classes', but modified if least_cost
deprecated config options are used, as mentioned above.

The RamWeigher class introduces a new config option
'ram_weight_multiplier'.  The default of 1.0 causes weights equal to the
free memory in MB to be returned, thus hosts with more free memory are
preferred (causes equal spreading).  Changing this value to a negative
number such as -1.0 will cause reverse behavior (fill first).

DocImpact

Change-Id: I1e5e5039c299db02f7287f2d33299ebf0b9732ce
Merge "Fixes usage of migrate_instance_start"
Merge "Add module for loading specific classes"
Merge "Refactor scheduling filters"