non-FS based Storage Repository will be supported after vdi streaming
patches finished. Remove SR limitation in the document.
Change-Id: Idaf461c849ac28b46e8971e5dd2f0e986a9a5c32
With the new image handler, it creates an image proxy which
will use the vdi streaming function from os-xenapi to
remotely export VHD from XenServer(image upload) or import
VHD to Xenerver(image download).
The existing GlanceStore uses custom functionality to directly
manipulate files on-disk, so it has the restriction that SR's
type must be file system based: e.g. ext or nfs. The new
image handler invokes APIs formally supported by XenServer
to export/import VDI remotely, it can support other SR
types also e.g. lvm, iscsi, etc.
Note:
vdi streaming would be supported by XenServer 6.5 or above.
The function of image handler depends on os-xenapi 0.3.3 or
above, so bump os-xenapi's version to 0.3.3 and also declare
depends on the patch which bump version in openstack/requirements.
Blueprint: xenapi-image-handler-option-improvement
Change-Id: I0ad8e34808401ace9b85e1b937a542f4c4e61690
Depends-On: Ib8bc0f837c55839dc85df1d1f0c76b320b9d97b8
1. url for `Ceilometer` doc is not correct
2. nova-cert has been removed
(change I2c78a0c6599b92040146cf9f0042cff8fd2509c3)
and should no appear in the example
3. phrasing issue in explanation for "used_now" of host resource
usage
4. 'opensack server list' repsonse is different from that of 'nova list'
5. add info about diagnostic statistics format
Change-Id: I6a2a7b396fee2a5cbae633d5c259f5f0961b9b60
There is concern over the ability for compute nodes to reasonably
determine which events should count against its consecutive build
failures. Since the compute may erronenously disable itself in
response to mundane or otherwise intentional user-triggered events,
this patch adds a scheduler weigher that considers the build failure
counter and can negatively weigh hosts with recent failures. This
avoids taking computes fully out of rotation, rather treating them as
less likely to be picked for a subsequent scheduling
operation.
This introduces a new conf option to control this weight. The default
is set high to maintain the existing behavior of picking nodes that
are not experiencing high failure rates, and resetting the counter as
soon as a single successful build occurs. This is minimal visible
change from the existing behavior with default configuration.
The rationale behind the default value for this weigher comes from the
values likely to be generated by its peer weighers. The RAM and Disk
weighers will increase the score by number of available megabytes of
memory (range in thousands) and disk (range in millions). The default
value of 1000000 for the build failure weigher will cause competing
nodes with similar amounts of available disk and a small (less than ten)
number of failures to become less desirable than those without, even
with many terabytes of available disk.
Change-Id: I71c56fe770f8c3f66db97fa542fdfdf2b9865fb8
Related-Bug: #1742102
It's more common to format words like "nova-compute" with "``"
instead of "`", and there is no need to format words like "RPC".
This patch also fixes a few syntax and typo issues.
And as requested, some typos in aggregates.rst are corrected to
improve readability.
Change-Id: I4d9c184e1448c8ea9973302f53e1773a7b66cd1e
This adds a new CLI which will iterate all non-cell0
cells looking for instances that (1) have a host,
(2) aren't undergoing a task state transition and
(3) don't have allocations in placement and try
to allocate resources, based on the instance embedded
flavor, against the compute node resource provider
on which the instance is currently running.
This is meant as a way to help migrate CachingScheduler
users off the CachingScheduler by first shoring up
instance allocations in placement for any instances
created after Pike, when the nova-compute resource
tracker code stopped creating allocations in placement
since the FilterScheduler does it at the time of
scheduling (but the CachingScheduler doesn't).
This will be useful beyond just getting deployments
off the CachingScheduler, however, since operators
will be able to use it to fix incorrect allocations
resulting from failed operations.
There are several TODOs and NOTEs inline about things
we could build on top of this or improve, but for now
this is the basic idea.
Change-Id: Iab67fd56ab4845f8ee19ca36e7353730638efb21
The trusted vf attribute will be exposed to the instance through the
metadata API and on the config drive.
Note the logic when dealing with NetworkInterfaceMetadata devices was
refactored slightly in order to handle the existing cases where these
types of devices are skipped.
Implements blueprint sriov-trusted-vfs
Change-Id: Icbac4f11b2383b3d8295ec3362db0fc60b9c35a9
Signed-off-by: Sahid Orentino Ferdjaoui <sahid.ferdjaoui@redhat.com>
This patch is the first step in syncing the nova host aggregate
information with the placement service. The scheduler report client gets
a couple new public methods -- aggregate_add_host() and
aggregate_remove_host(). Both of these methods do **NOT** impact the
provider tree cache that the scheduler reportclient keeps when
instantiated inside the compute resource tracker.
Instead, these two new reportclient methods look up a resource provider
by *name* (not UUID) since that is what is supplied by the
os-aggregates Compute API when adding or removing a "host" to/from a
nova host aggregate.
Change-Id: Ibd7aa4f8c4ea787774becece324d9051521c44b6
blueprint: placement-mirror-host-aggregates
This change adds vSCSI Fibre Channel volume support via cinder for the
PowerVM virt driver. Attach, detach, and extend are the supported
volume operations by the PowerVM vSCSI FC adapter. PowerVM CI volume
tests are run on-demand only which can be done by leaving a comment
with "powervm:volume-check".
Blueprint: powervm-vscsi
Change-Id: I632993abe70f9f98a032a35891b690db15ded6a0
This adds a request filter that, if enabled, allows us to use placement
to select hosts in the desired availability zone by looking up the uuid
of the associated host aggregate and using that in our query for
allocation candidates. The deployer needs the same sort of mirrored
aggregate setup as the tenant filter, and documentation is added here to
make that clear.
Related to blueprint placement-req-filter
Change-Id: I7eb6de435e10793f5445724d847a8f1bf25ec6e3
Change If507e23f0b7e5fa417041c3870d77786498f741d makes nova-api
dependent on placement for deleting an instance when the nova-compute
service on which that instance is running is down, also known as
"local delete".
Change I7b8622b178d5043ed1556d7bdceaf60f47e5ac80 makes nova-api
dependent on placement for deleting a nova-compute service record.
Both changes are idempotent if nova-api isn't configured to use
placement, but warnings will show up in the logs.
This change updates the upgrade docs to mention the new dependency.
Change-Id: I941a8f4b321e4c90a45f7d9fccb74489fae0d62d
Related-Bug: #1679750
Related-Bug: #1756179
Change Id7eecbfe53f3a973d828122cf0149b2e10b8833f made
nova-scheduler require placement >= 1.24 so this change
updates the minimum required version checked in the
nova-status upgrade check command along with the upgrade
docs.
Change-Id: I4369f7fb1453e896864222fa407437982be8f6b5
Option "os_region_name" from group "placement" is deprecated. Use
option "region_name" from group "placement".
Change-Id: Id44d456bb1bdb0c5564ad4f5d9cdee2f41226052
Related-Bug: #1762106
Some workloads run best when the hypervisor overhead processes
(emulator threads in libvirt/QEMU) can be placed on different physical
host CPUs than other guest CPU resources. This allows those workloads
to prevent latency spikes for guest vCPU threads.
To ensure emulator threads are placed on a different set of physical
CPUs than those running guest dedicated vCPUs, set the
``CONF.compute.cpu_shared_set`` configuration option to the set of host
CPUs that should be used for best-effort CPU resources. Then set a
flavor extra spec to ``hw:emulator_threads_policy=share`` to instruct
nova to place that workload's emulator threads on that set of host CPUs.
implement: bp/overhead-pin-set
Signed-off-by: Sahid Orentino Ferdjaoui <sahid.ferdjaoui@redhat.com>
Change-Id: I0e63ab37d584ee3d7fde6553efaa61bfc866e67d
This adds a granular policy checking framework for
placement based on nova.policy but with a lot of
the legacy cruft removed, like the is_admin and
context_is_admin rules.
A new PlacementPolicyFixture is added along with
a new configuration option, [placement]/policy_file,
which is needed because the default policy file
that gets used in config is from [oslo_policy]/policy_file
which is being used as the nova policy file. As
far as I can tell, oslo.policy doesn't allow for
multiple policy files with different names unless
I'm misunderstanding how the policy_dirs option works.
With these changes, we can have something like:
/etc/nova/policy.json - for nova policy rules
/etc/nova/placement-policy.yaml - for placement rules
The docs are also updated to include the placement
policy sample along with a tox builder for the sample.
This starts by adding granular rules for CRUD operations
on the /resource_providers and /resource_providers/{uuid}
routes which use the same descriptions from the placement
API reference. Subsequent patches will add new granular
rules for the other routes.
Part of blueprint granular-placement-policy
Change-Id: I17573f5210314341c332fdcb1ce462a989c21940
The top level index (home page) was duplicating the
configuration/index content, so this simply changes
the home page into a table of contents for the configuration
sub-tree and leaves the config/policy content in the
sub-tree. This will be needed when we add docs about
placement policy.
The hidden configuration toc tree items are moved
into the sub-tree configuration/index to be closer
to the actual documents we're hiding from the toc tree.
Related to blueprint granular-placement-policy
Change-Id: Iad87dc339278ee7e7cf8de5eea252bbb7a5f75c2
1. Beginning with the Queens release, the keystone install guide
recommends running all interfaces on the same port. This patch
updates the install guide to reflect that change.
2. update the deprecated neutron auth options
Change-Id: I5c0a6389b759153bae06fa43846f03ac083c3db4
naichuans