There are two types of VM states associated with shelving. The first,
'shelved' indicates that the VM has been powered off but the resources
remain allocated on the hypervisor. The second, 'shelved_offloaded',
indicates that the VM has been powered off and the resources freed.
When "unshelving" VMs in the latter state, the VM state does not change
from 'shelved_offloaded' until some time after the VM has been
"unshelved".
Change I83a5f06 introduced a change that allowed for deallocation of
resources when they were set to the 'shelved_offloaded' state. However,
the resource (de)allocation code path assumes any VM with a state of
'shelved_offloaded' should have resources deallocated from it, rather
than allocated to it. As the VM state has not changed when this code
path is executed, resources are incorrectly deallocated from the
instance twice.
Enhance the aformentioned check to account for task state in addition to
VM state. This ensures a VM that's still in 'shelved_offloaded' state,
but is in fact being unshelved, does not trigger deallocation.
Change-Id: Ie2e7b91937fc3d61bb1197fffc3549bebc65e8aa
Signed-off-by: Stephen Finucane <stephen.finucane@intel.com>
Resolves-bug: #1587386
Related-bug: #1545675
This change modifies the exception handling when Nova's
image signature verification fails so that the build is
aborted and instance's fault shows the error.
Change-Id: I05d877fe92593edaaa8b93b87b4b787827cae8f0
Closes-bug: #1594385
In order to expose device tagging metadata in the configdrive, the
latter needs to be attached after the instance XML has been generated
and device addresses are known, but before the guest OS runs, as
it may depend on cloud-init data on the config drive.
This patch moves configdrive creation after the instance XML has
been generated but before the guest runs.
Partially implements: blueprint virt-device-role-tagging
Co-authored-by: Vladik Romanovsky <vromanso@redhat.com>
Change-Id: I931421ea688641e2ceb212c6dc099639c53433f2
The instance booting helper functions will be reused by the
subsequent patches so it is moved to a common place.
Change-Id: I4684df49a5301ac3ffcdd2213164925514a1d1c2
Adds 'fatal' argument (with default value True) to context.
If the argument is False, if a nova.exception.Forbidden
is raised, False is returned instead. This is the equivalent of
soft_authorize.
Adds docstring to nova.context.RequestContext.can.
Adds unit tests for nova.context.RequestContext.can.
Partially-Implements: bp policy-in-code
Change-Id: Ib6388822da3d3eb9b8fbd9b5c341cd8efeb790fe
Add the independent compute option and ensure appropriate failure cases
for all incompatible options.
Change-Id: I76c1e3a80da8142639328b204aea5da59551eea3
Implements-blueprint: xenapi-independent-nova
Rather than mounting a guest disk into the compute node,
create the config drive locally and stream it to the
XenServer hypervisor.
Change-Id: I324538decbadf63e78ba86e20e3d41687b0a195a
Implements-Blueprint: xenapi-independent-nova
Move some disk operations from DomU to Dom0 to allow Nova
to run independently from the hypervisor.
Some disk types can be created in Dom0 (e.g. swap, ext3) but
others cannot. Add support here for creating those that can
in Dom0. This will be documented in the independent_compute
config flag in the last patch in this series.
Implements: blueprint xenapi-independent-nova
Change-Id: I634e783a5e19f9710544920e12300b299fc06b36
The values reported by a monitor depends on the type of value which
will not be uniform for all the monitors. For example, the memory
bandwidth monitor will return a dict of ints while the cpu monitor
returns a normal int value. The monitor metric objects offer
different fields to be set depending on the monitor in question.
This patchset allows the monitors to decide what metric field
it would like to populate as over a general implementation of
creating the monitor metric object inside the base module.
This would also help in exchanging versioned objects between
the monitors and the compute drivers.
Eventually this work will lead up to making the metrics.update
notification as versioned.
Related to blueprint memory-bw
Co-Authored-By: Ahilan Rajadeva <rajadeva@us.ibm.com>
Change-Id: Ieaf3d44bbe73e71ad877199bbbc779afa4218b51
The order of APIs in server-tags isn't match the rule as other api
ref docs. This patch correct it.
Part of bp:api-ref-in-rst
Change-Id: Ie1a43863e4ede4f7a1e028131248263e9c5a434f