Add flavor-access to core for V3 API

Adds the flavor-access plugin to the core list for the V3 API.
This is part of the process of adding all of the flavor related
extensions to core, with the exception of rxtx, as per the discussion
here: https://etherpad.openstack.org/p/NovaV3APICore

Note that since the alias changes from os-flavor-access to flavor-access
the api samples move directory and quite a few of other api samples
as well as flavor access is included by default.

Partially implements blueprint nova-v3-api

DocImpact

Change-Id: I9abc7df8f4620d462b0d381a2c0ed180c48f220e
Add flavor-extra-specs to core for V3 API

Adds the flavor-extra-specs plugin to the core list for the V3 API.
This is part of the process of adding all of the flavor related
extensions to core, with the exception of rxtx, as per the discussion
here: https://etherpad.openstack.org/p/NovaV3APICore

Partially implements blueprint nova-v3-api

Change-Id: Id4b4fad5e584bdf2bbbaaae579a07e28c312ef34
Removed unused instance object helper function

Remove code that is no longer used

Change-Id: Iaf99824ad28aa03206a997e69d9f6097ba034941
Remove V3 API version of coverage extension

As discussed at the summit in the QA session, this removes
the coverage extension from the V3 API. The coverage extension
doesn't work properly and has security issues. An alternative technique,
though more limited in nature will soon be proposed.

Partially implements blueprint nova-v3-api

Change-Id: Ib4296288fefeb7e1e11bb6e44bd1cf355f29b9b9
Remove V2 API version of coverage extensions

As discussed at the summit in the QA stream, this removes
the coverage extension from the V2 API.

According to the API Change Guidelines
https://wiki.openstack.org/wiki/APIChangeGuidelines
we should not be doing this. However the coverage
extension is a rather special case. It has security issues
such that it shouldn't be used in a production cloud
environment. It also doesn't work properly so its usefulness
to measure API coverage is limited. And in the past the presence of
this plugin has been used as a reason not to accept
an alternative technique to measure API coverage.

This is the proposed replacement

https://review.openstack.org/#/c/25882/

Change-Id: I07d798129ee277a6f7691c25f88c07a5204c0943
Add a driver method to toggle instance booting

Add a driver method to toggle the ability to boot an instance.

The only implementation provided is for the xenapi virt driver.  Other
drivers will log a warning and treat the method as a no-op.

Implements: blueprint cleanup-running-deleted-shutdown

Change-Id: Ie448c681d653b126cb12d3a48d79ab4febde8828
objects: declare some methods as static

A lot of code is composed of static methods, but they are not declared
as is.

Change-Id: I64be630b560e331aed9d1ab9a68152da52eb0d82
Use model_query() instead of session.query in db.instance_destroy

Unify db.instance_destroy() method to use model_query() as others
methods use.

Side effect we won't try to soft delete already soft deleted instance

Change-Id: I36d5bb42b16901c260ff4276e31a6aec46ffa8a4
handle migration errors

handle errors:
   MigrationPreCheckError, NoValidHost,
   InvalidSharedStorage and InvalidLocalStorage
in _migrate_live so that the 'reason' is passed up

Closes-Bug: 1250523

Change-Id: I3d7e0626223f2606c5e7205e5022e26585506cfb
Fix missing format specifier in ImagePropertiesFilter log message

Commit a52259e introduced some changes to debug log messages in the
ImagePropertiesFilter but with that came a bug due to a missing format
specifier.

Closes-Bug: #1253875

Change-Id: Ic60b7ba179bd43b80c500be084a1809b6b0b32ca
Use of logging in native thread causes deadlock connecting to libvirtd

When connecting to libvirtd daemon we were calling the _connect
method in a native thread. The use of logging in this method hit this
bug in eventlet https://bitbucket.org/eventlet/eventlet/issue/137/
causing nova-compute to hang.

Closes-Bug: #1252409

Change-Id: I0d22c3ed1b3288aeb1afae130f11a4f38dc6440a
Adjust the order of notification for shelve instance

When shelve instance, if CONF.shelved_offload_time == 0, then the
notification order for shelve_instance() is as following:
1) compute.instance.shelve.start
2) compute.instance.shelve_offload.start
3) compute.instance.shelve_offload.end
4) compute.instance.shelve.end

This order is not correct, as actually before shelve_offload.start,
the instance was already reached shelve.end, so we should adjust the
order of notification for shelve instance as following:
1) compute.instance.shelve.start
2) compute.instance.shelve.end
3) compute.instance.shelve_offload.start
4) compute.instance.shelve_offload.end

Change-Id: I6e075b3f29e1c3f641ab1e459e1fbe3b05869a9a
Closes-Bug: #1248802
Improved debug ability for log message of cold migration

When cold migration failed because of nova scheduler return no
valid host, conductor only log no valid host, but did not specify
which instance failed.

This patch was specifying instance in the failure log for cold
migration.

Change-Id: Ia9e42f8f253323fb35a58e0be2a24ab043204d29
baremetal: Make api validate mac address

Check if the address in the form of xx:xx:xx:xx:xx:xx.

Closes-Bug: 1238595
Change-Id: Idcba745a011604d7664b62d88f1dede88d10443d
Bump to sqlalchemy-migrate 0.8.2

This allows us to drop some unsightly
0.7.3 patching and also avoids potential
issues in using 0.8.1 which had a bad
release version string (it was called '0.7.3dev' by mistake).

This will require a requirements change here:

 https://review.openstack.org/56662

Change-Id: I5f80dfc07f8256716d025002fc1a1f47e58b2142
Closes-Bug: 1251700
Supplement 'os-migrateLive' in actions list

The test for actions with non existed instance missing the action
'os-migrateLive'.

Change-Id: Ia36c369d60bea9500cc5a64be7971e60cbe79377
Closes-Bug: #1255023
Fix some i18n issue in nova/compute/manager.py

Some exceptions in nova compute manager did not follow i18n coding
style, just fix them.

Change-Id: I9cc18c05419508232062c749c0f9740c5241469d
instance state will be stuck in unshelving when unshelve fails

When unshelve an instance, if this instance has been offloaded,
the conductor manager will involve re-schedule for the instance.
If re-schedule failed to find a target host for the unsleved
instance, then the instance will be stuck in unshelving state.

This patch fix the issue as this: If re-schedule failed to find a
target host for unshelve the instance, then conductor manager will
try to rollback the instance to unshelve state.

Change-Id: If49b2d2c9263b853c745ce25fe146ade51948123
Closes-Bug: #1248799
Change ConductorManager to self.db when record cold_migrate event

In conductor manager, when cold migrate an instance, conductor
manager will record event of cold_migrate.

When record this event, conductor manager pass ConductorManager but
not self.db as parameter for compute_utils.EventReporter(), as we
can access the db directly from conductor manager so going through
ConductorManager as a proxy is unnecessary.

Change-Id: Ic52228c2550294c2df37d10d36637e4d0e3a1a30
Remove duplicate BuildAbortException block

Somehow, most likely due to a bad rebase, there were two
BuildAbortException blocks in the same section.  This removes one.

bp remove-cast-to-schedule-run-instance

Change-Id: I29684e222f18e6da280ed181447750525d878423