The formatting of the console commands is inconsistent between the
endpoint creation of the `compute` and the `placement` services. This
change reformats the commands.
Change-Id: I18f1cb8d5b3335d03e20c955c3c901b8dc1a8129
The CreateAndConnectCfgDrive and DeleteVOpt tasks were passing the
instance into the task.Task init as the first argument. The first arg
for the Task init is actually the task name [1]. This means that those
task names were string representations of the instance which will cause
failures if there are any non-ascii characters. This corrects the Task
init calls by removing instance as the first argument. The name kwarg
is now being used throughout the PowerVM tasks to avoid similar issues
in the future.
[1] https://github.com/openstack/taskflow/blob/3.1.0/taskflow/task.py#L62
Change-Id: I991a5ea33daa9a21f774fe24882ed40f990b8e0e
Closes-Bug: #1748950
This moves the legacy-tempest-dsvm-neutron-nova-next-full
job from openstack-zuul-jobs in-tree and updates a
few things since it's now branch specific:
- The cells v2 and placement stuff can be removed since those
are required now (they were optional when this job would run
against newton changes).
- Use nova/gate/post_test_hook.sh rather than the symlink under
nova/tools/hooks/.
The job is currently non-voting and needs to remain that way
until bug 1747511 is fixed.
According to the branch restrictions in project-config, apparently
this job is only running against stable/newton (which no longer
exists) and master, presumably when master was pike. We should also
run this job against stable/pike for the service user test coverage
and post_test_hook.sh run, so we'll likely backport this change
to stable/pike as well.
The related project-config change is:
I36d96f89b3e5323746fcbcef5cc7e4d0384a184d
Change-Id: I24a5f73c29094a23e2fdef8ee8b43601300af593
When Change-Id: I61d20c5d19797f7e66648c7864a632f3328be8ce was under
review there were questions about why the interface on deploy() was not
changed to remove the no-longer used project_name kwarg. I mistakenly
asserted that this was because it was a public interface for building
a Placement WSGI application. That's not the case. loadapp() is the
public interface.
This change annotates loadapp() as such, and removes the unused arg
deploy().
Change-Id: I9f3d03d964654ab1b9515ecd6fe35c518d5f496a
Related-Bug: #1734491
The docs were using variable names from the filter code rather
than the actual config options.
Change-Id: I2694b32e9c90ad098101e41e4e3ae36ddafd8d0f
Related-Bug: #1746483
The RequestSpec.image object for a volume-backed instance will
not have the 'id' attribute set because the
nova.utils.get_image_metadata_from_volume() method doesn't convert
the volume['volume_image_metadata']['image_id'] into the ImageMeta.id
field. It is unclear if there are intentional reasons for omitting
this information, but the IsolatedHostsFilter has just never supported
filtering for volume-backed instances based on a provided image id.
The logic within the filter depends on the
restrict_isolated_hosts_to_isolated_images config option, which
defaults to True. When True, a volume-backed instance will not be
put on an isolated host. When False, a volume-backed instance can
go on any host, isolated or not.
Again, it's unclear if we should actually be filtering volume-backed
servers using the image_id from the volume_image_metadata or not,
but it's not what we've historically done so this change simply
fixes the regression bug.
Change-Id: Ieb8abb1a3f04ce008f9617e051e4d720dbe6917a
Closes-Bug: #1746483
Creating a volume-backed server while using the IsolatedHostsFilter
results in a NoValidHost failure because the filter tries to load
the RequestSpec.image.id but when you create a server from a volume,
an image is not required directly in the server create request.
Change-Id: Id21e0afa5cec401555bee679193c256e55be863b
Related-Bug: #1746483
The explanation of NUMA topology feature of nova exited in both
numa.rst and cpu-topologies.rst under doc/source/admin/.
This patch merges them for cleaning up.
Change-Id: I35e23b2e1ac55c74faf4f0542498e45f2957e4d3
Add the 'X-Openstack-Request-Id' header
in the request of GET in SchedulerReportClient.
Change-Id: I306ac6f5c6b67d77d91a7ba24d4d863ab3e1bf5c
Closes-Bug: #1734625
Add the 'X-Openstack-Request-Id' header
in the request of PUT in SchedulerReportClient.
When removing a resource provider from an instance allocation
and putting allocations to a resource provider,
the header is added.
Subsequent patches will add the header in the other cases.
Change-Id: I7891b98f225f97ad47f189afb9110ef31c810717
Partial-Bug: #1734625
Previously, SchedulerReportClient.set_inventory_for_provider used this
logic to pre-create custom resource classes found in the input
inventory.
list(map(self._ensure_resource_class,
(rc_name for rc_name in inv_data
if rc_name not in fields.ResourceClass.STANDARD)))
...where _ensure_resource_class would always attempt to create the
resource class it was given, and raise an exception if that failed for
any reason. Note in particular that attempting to create an
already-extant "standard" resource class will fail just the same as
attempting to create any nonexistent resource class that doesn't conform
to the schema (i.e. beginning with "CUSTOM_").
The problem is that this relies on the local system's notion of the set
of standard resource classes. If the placement service is running newer
code, standard resource classes may have been added that the compute
service doesn't know about yet.
This change set solves the problem by only attempting to create resource
classes with the 'CUSTOM_' prefix.
self._ensure_resource_class (which worked on a single resource class) is
replaced with self._ensure_resource_classes (plural) which accepts a
list of *all* the desired resource classes (including the standard
ones), filters down to the CUSTOM_* ones, and attempts to create the
remainder.
Note that if placement ever decides to start allowing creation of
resource classes with prefixes other than CUSTOM_, it will have to do so
under a new microversion, so we can't future-proof this by e.g.
prefetching all the known resource classes from placement and attempting
to create any not found in that list.
In the process of doing this rework, obsolete code paths relying on
pre-1.7 placement microversions are removed.
Change-Id: I600ed262e1b5d11facbf461e28291193665280cf
Closes-Bug: #1746615
Nova has two pages in documentation listing things supported on several
architectures/hypervisors. This patch adds initial state of AArch64
into support matrix.
Document minimal qemu/libvirt for aarch64. Version 3.6.0 was first one
which worked for us with Nova without a need for extra patches.
Change-Id: I2ee7be9e88e20ed0f77be07fed4fdd800533b3c5
The 345 DB migration shows error messages by combining base_msg
and each specific message, but it was not readable due to lack of
a space. This patch fixes it.
This comes from a review of Ie83e7bd807c2c79e5cbe1337292c2d1989d4ac03
Change-Id: I277d0bf9e392c969fcf0721ee1588e3e65d4650a
Zuul