GitLab

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

While getting a HostState object for a given compute node during
scheduling, if the HostState does not have its instance info
set, either because it's out of date or because config option
"track_instance_changes" is False, the HostManager still pulls
the list of instances for that host from the database and stores
it in HostState.instances.

This is *only* used (in-tree) by the affinity filters and even
then the only thing those filters use from HostState.instances
is the set of keys from the dict, which is the list of instance
UUIDs on a given host. The actual Instance objects aren't used
at all. See blueprint put-host-manager-instance-info-on-a-diet
for more details on that.

The point of this change, is that when we go to pull the set
of instances from the database for a given host, we don't need
to join on the default columns (info_cache and security_groups)
defined in the _instance_get_all_query() method in the DB API.

This should be at least some minor optimization in scheduling
for hosts that have several instances on them in a large cloud.
As noted in the comment in the code, any out of tree filters
that rely on using the info_cache or security_groups from the
instance are now going to be hit with a lazy-load penalty
per instance, but we have no contract on out of tree filters
so if this happens, the people maintaining said filters can
(1) live with it (2) fork the HostManager code or (3) upstream
their filter so it's in-tree.

A more impactful change would be to refactor
HostManager._get_host_states to bulk query the instances on
the given set of compute nodes in a single query per cell. But
that is left for a later change.

Change-Id: Iccefbfdfa578515a004ef6ac718bac1a49d5c5fd
Partial-Bug: #1737465

This is needed for ironic use case, when during cleaning, resources
are reserved by ironic itself. Cyborg will also benefit from this
during FPGA programming.

blueprint: allow-reserved-equal-total-inventory
Change-Id: I037d9b8c1bb554c3437434cc9a57ddb630dd62f0

This refreshes the PowerVM hypervisor docs with a clearer flow and
additional information.

Change-Id: I0b33200b710960e4e8df7333d06c98456c4b0c00

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

nova.scheduler.utils.ResourceRequest now has a to_querystring method
that produces a querystring in the format expected by the GET
/allocation_candidates API.  The report client now uses this method to
invoke said API.

Change-Id: I496e8d64907fdcb0e2da255725aed1fc529725f2
blueprint: granular-resource-requests

The has_inventory_changed method of ProviderTree is deliberately not
automatically reporting True if the incoming record is "sparse" - that
is, for a given resource class, it only contains a subset of the keys in
the existing record.  For example, the caller may want to know if the
total has changed, but doesn't care about the other fields, so may ask:

ptree.has_inventory_changed(uuid, {'VCPU': {'total': 3}, ...})

...and has_inventory_changed will only compare the 'total' field.

However, we were doing the same if the incoming record contained fields
that were *not* in the existing record.  For example, if the current
inventory was:

{ 'VCPU': {
      'total': 8,
      'min_unit': 1,
      'max_unit': 8,
      'step_size': 1,
  }
}

...and the new inventory was:

{ 'VCPU': {
      'total': 8,
      'min_unit': 1,
      'max_unit': 8,
      'step_size': 1,
      'allocation_ratio': 16.0,  # <== new
      'reserved': 1,             # <== new
  }
}

...the presence of the new fields was *not* enough to trigger a True
response.

This is problematic because we currently expect to be able to add
specifically these fields - allocation_ratio and reserved - to an
inventory record if they are not present (see [1]).

With this change set, we add a condition to automatically return True
(inventory *has* changed) whenever the incoming (new) record contains
fields absent from the existing record.

[1] https://github.com/openstack/nova/blob/050e9202f69b6eeb23026b7350eeb8821ca9f1cc/nova/compute/resource_tracker.py#L83-L125

Partial-Bug: #1771728
Change-Id: I80dd6d08322bcedc8535f04baf2e96473f5e3aeb

Add PowerVM Driver support for local ephemeral disk.

Change-Id: I9251287451bc2f800ef4a230c3c01598f37b5ad3
Blueprint: powervm-localdisk

We've had a long-standing optimization point in the
InstanceList.get_uuids_by_host() method, where we pull the entire
list of instance objects only to strip and return the uuids. We
already had a query method for generating just the uuids in the
DB API, but it was not exposed as it was just a helper for another
method. This exposes it publicly and uses it in that InstanceList
method.

Change-Id: I35c05e78d59ec9b95c2a443979b8d66cd42ea043

The instance.refresh() method is careful to prevent recursion, to avoid
lazy-loads on the object we just pulled from the database. However, it
was allowing those to raise OrphanedObjectError to the caller to make
them visible. The caller is not really at fault in that case, and can not
avoid it.

The only time this has ever come up is in the context of cellsv1 and the
keypairs field that it doesn't have set on instances in the child cells.
Thus, this changes refresh() to just skip fields that are set on the
current object and unset on the one we pull from the database, as we
would not be able to refresh those anyway. This logs the situation so that
it is visible (at DEBUG) if it becomes relevant.

Change-Id: Ibfca4ae922766b5b977e217594d12e1169ddeee8

Previously we had a trivial block on the lazy-load handler for instance
that prevented loading mundane things that couldn't be opted-out during
a query. There's no real reason for that and we already had the generic
loader mechanism.

This removes that limit, and adjusts some of the logic in obj_load_attr()
to continue providing the same behavior for things like id and uuid being
missing (which we have lots of existing coverage for). The new behavior
of being able to load something like vm_state gets a new test, which also
validates that _load_generic() loads anything else it can from the instance
it fetches from the database, if not already set on the object initiating
the load.

Change-Id: Id0f4027f1fffefdb90240fc484cf3c0554e576d9

Since max_attempts is not max_retries, we should look for max_attempts-1
alternate hosts. This change makes the num_alts variable actually reflect
the number of alternates we are looking for, and doesn't actually change
the logic at all. This also adds functional tests to verify max_attempts
behavior with 1 (no retries) and 2 (one retry), just to make sure it is
doing what we expect.

Further, we optimize _get_alternate_hosts() to only re-filter/weigh the
host list if we're looking for alternates for multiple instances. Now
that it's clear that num_alts is only nonzero if we are going to look
at the host list again to find those alternates, it can be more clearly
(and accurately) used to optimize out that extra step if we are not
getting alternates.

Change-Id: I16ba29385dd2db5467829e6c17fc395096b5cfd3

Option "os_region_name" from group "placement" is deprecated. Use
option "region_name" from group "placement".

Change-Id: Id44d456bb1bdb0c5564ad4f5d9cdee2f41226052
Related-Bug: #1762106

  * Make the `True` lowercase to reflect examples in config and
    other parameters in docs

TrivialFix

Change-Id: I259d36bc15e034c248ec39b2c5c97ff95986b31b

According to libvirt doc[1], migrateToURI3 supports
args(dconnuri, params, flags) but not logical_sum.
We call migrateToURI3 with arg flags in guest.py [2].

The wrong fake func may cause error in functional tests of nova.
With logs below:
  "/home/zuul/src/git.openstack.org/openstack/nova/nova/virt/libvirt/guest.py",
  line 669, in migrate'
  '    destination, params=params, flags=flags)'
  "TypeError: migrateToURI3() got an unexpected keyword argument 'flags'"

[1] https://libvirt.org/html/libvirt-libvirt-domain.html#virDomainMigrateToURI3
[2] https://github.com/openstack/nova/blob/050e92/nova/virt/libvirt/guest.py#L668

Change-Id: I88d71bac7ddb69b9b63fb58dd8eaf6c048017933