This introduces a new PowerVM conf option, proc_units_factor, which can
range from 0.05 to 1.0 and will default to 0.1. It is used to calculate
the physical processing power to assign per vCPU, where 1.0 is a whole
physical processor and 0.05 is 1/20th of a physical processor.
Change-Id: I67bfe2a6eff86f1947ada7661fc7c3fed81ed28f
The resource tracker calls the new update_provider_tree virt driver
method - using it if available, falling back to the existing
get_inventory-if-available business if not - and flushes the changes
back to placement accordingly.
Change-Id: I5ee11274816cd9e4f0669e9e52468a29262c9020
blueprint: update-provider-tree
Once the resource tracker has asked the compute driver to
update_provider_tree, it needs to flush any changes back to placement.
This change set introduces update_from_provider_tree to
SchedulerReportClient. This method accepts the ProviderTree as modified
by ComputeDriver.update_provider_tree, compares it to what the report
client has in its cache, and flushes any changes back to the placement
service.
Change-Id: I9064a2598d773a814269995eed8862d093d9100e
blueprint: update-provider-tree
Co-Authored-By: Radoslav Gerganov <rgerganov@vmware.com>
Depends-On: https://review.openstack.org/536545
In `test_allocation_candidates.py`, there are some tests that
validate `allocation_requests` without checking `provider_summaries`.
This patch complements the tests by adding to the test functions
`_validate_provider_summary_resources`, a base test to check
what is in `provider_summaries`.
This change will help us build new features such as nested and
shared providers without breaking the existing behavior.
Change-Id: Ifa7a21a1f83f4a23747d1c6316d9bffcf158ff9a
In ``GET /allocation_candidates`` API, ``provider_summaries``
should show all the inventories for all the resource classes
in all the resource providers.
However, ``provider_summaries`` currently doesn't contain
resources that aren't requested.
This patch adds a simple test case to describe the bug.
Change-Id: Ida9cddc5a2b43917e7b5900fe68a413b18c6cb2d
Partial-Bug: #1760276
Recently [1] oslo.config started pawing at stack traces and adding
source filename locations to options set in code. This breaks pretty
handily when you've got primitives like open and os.patch.exists mocked
while you set conf options, as seen in [2].
This patch cleans up *just* the failing instances by pulling the mocks
closer to where they're actually being used, avoiding self.flags(...).
This isn't going to stop anyone from writing new tests that offend in
the same way. The new oslo.config will, once it gets published, though
people are going to scratch their heads trying to figure out why.
See also dev ML thread [3].
[1] I6dec1e09dcab203c6287f9c56c866f220a42f850
[2] http://logs.openstack.org/12/557012/1/check/cross-nova-py27/37b2a7c/job-output.txt.gz#_2018-03-27_21_41_09_883881
[3] http://lists.openstack.org/pipermail/openstack-dev/2018-March/128833.html
Change-Id: I6484984c374b20351aa406aa91beacf8ee503059
This by default would be scheduling to all cells since all cells
would be enabled at the time of creation unless specified otherwise.
Since the list of enabled cells are stored as a global cache on the
host_manager, a reset() handler for the SIGHUP signal has also been
added in the scheduler. Hence upon every create-cell/enable-cell/
disable-cell operation the scheduler has to be signaled so that the
cache is refreshed.
Co-Authored-By: Dan Smith <dms@danplanet.com>
Implements blueprint cell-disable
Change-Id: I6a9007d172b55238d02da8046311f8dc954703c5
Change I2c86989ab7c6593bf346611cde8c043116d55bc5 way back in Essex
added the "setup_network_on_host" network API calls to the migration
flows, including rollback_live_migration_at_destination. The initial
implementation of that method for Quantum (Neutron) was a no-op.
Change Ib1cc44bf9d01baf4d1f1d26c2a368a5ca7c6ab68 in Newton added the
Neutron implementation for the setup_networks_on_host method in order
to track the destination host being migrated to for instances that
have floating IPs with DVR.
When rolling back from a live migration failure on the destination host,
the "migrating_to" attribute in the port binding profile, added in
pre_live_migration() on the destination compute, is cleared.
However, that only happens in rollback_live_migration_at_destination,
which is only called if the instance is not on shared storage (think
libvirt with the rbd image backend or with NFS). That's controlled
via the "do_cleanup" flag returned from _live_migration_cleanup_flags().
If the live migration is happening over shared storage and fails, then
rollback_live_migration_at_destination isn't called which means
setup_network_on_host isn't called, which means the "migrating_to"
attribute in the port binding profile isn't cleaned up.
This change simply adds the cleanup in _rollback_live_migration in the
event that neutron is being used and we're live migrating over shared
storage so rollback_live_migration_at_destination isn't called.
Change-Id: I658e0a749e842163ed74f82c975bcaf19f9f7f07
Closes-Bug: #1757292
A recent IRC conversation [1] discussed that there are generally no tests
for the placement handler code (the wsgi methods that respond to each
URI and HTTP method). This change adds a paragraph to point out that
this is mostly intentional and that when they get complex it would
be a good idea to extract a method.
[1] http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2018-03-28.log.html#t2018-03-28T13:00:40
Change-Id: I09774c123068e42e6a828fc37455dc5d374486b9
This change adds a trusted_certs object, which stores a list of trusted
x509 certificate IDs, to the Instance object.
Change-Id: I872b50932f7611584661efc604c8e5d4324fae9b
Implements: blueprint nova-validate-certificates
This change adds a trusted_certs deferred-load column to
instance_extras, which stores a list of trusted x509 certificate
UUIDs for a given instance in the form of a JSON blob.
Change-Id: I3fd4e395b31ff1b69f35242d559f8caa17c05a6a
Implements: blueprint nova-validate-certificates