These are left over from the objectification of live migration. We can
safely get rid of them. This isn't required for the NUMA live
migration series, but the presence of _legacy_dict methods caused unit
test failures in subsequent paches because of their failure to handle
the changes to LiveMigrateData. Rather than working around that, bite
the bullet and remove _legacy_dict altogether.
Change-Id: I01c108ceb539bb99491ed542c683e36fbf0c2bbe
This is a follow up for change
I0c764e441993e32aafef0b18049a425c3c832a50 to address
review comments.
The most important part is the early exit from
_fill_provider_mapping if request_spec.maps_requested_resources
returns False. That is needed to avoid the performance
impact of getting allocations and resource provider traits
per instance and provider. Since this code is currently only
going to be exercised with ports that have resource requests,
we want to avoid the extra work for all other server create
requests.
Part of blueprint bandwidth-resource-provider
Change-Id: I90845461b2b98c176c7b3b97dd3f47ed604a9bef
This patch fixes small comments from
Id7827fe8dc27112e342dc25c902c8dbc25f63b94
blueprint bandwidth-resource-provider
Change-Id: Ibb670c6d6d2c93bbc7a83352c6ed25b932499232
Use the previously introduced map_requested_resources_to_providers()
function in the RequestSpec during the scheduling of a new server. This
is done in the conductor becase later when placement will return such mapping
this will be the place when that mapping can be moved form the Selection
object returned by the scheduler to the RequestSpec.
blueprint bandwidth-resource-provider
Change-Id: I0c764e441993e32aafef0b18049a425c3c832a50
If the port, provided in the server create request, has requested
resources then nova needs to communicate the resource allocation it
made during the scheduling to neutron.
As a single neutron port's resource request is included in the
allocation candidate query as a separate request group therefore the
alloction for a port will come from a single RP. Neutron expects that
this single RP uuid is communicated during the binding of the port in
the binding_profile.
Each Neutron port's resource request is represented as a RequestGroup in
the RequestSpec.
This patch introduces a code in RequestSpec to map RequestGroups to
resource providers in a generic way, base on the resource requests and
required traits in the groups, the overall allocation made for the
RequestSpec and the provider summary of the RPs in the allocation.
Subsequent patches will integrate this code into the server create code
path to create the mapping, then change the port binding code path to
use this mapping to communicate the resource provider of the port in the
binding profile.
blueprint bandwidth-resource-provider
Change-Id: Id7827fe8dc27112e342dc25c902c8dbc25f63b94
This patch adds the documentation around the work regarding
handling down cells that was introduced in v2.69.
Related to blueprint handling-down-cell
Change-Id: I78ed924a802307a992ff90e61ae7ff07c2cc39d1
Currently functional tests cannot test the DELETE method on some API
endpoints, e.g.
DELETE /placement/traits/{name}
This is because it is not setting the request headers to have the
right microversion API - this setting was added for GET / PUT / POST
in I681712ac37f732c7803c68f6c7d1eae9f2877d3d, but not for DELETE.
Therefore the microversion defaults to 1.0 which for some endpoints is
lower than the required version, e.g. the endpoint above requires a
minimum microversion of 1.6, which is when this API was introduced.
This results in any invocation of _fake_delete() receiving a 404
error, although this error has not been experienced so far because
nothing uses _fake_delete() yet.
In order to enable future functional tests which hit this API call,
set the request headers in a manner consistent with the other HTTP
methods for the same endpoint.
Change-Id: I2e2d9a9ae12404fe66eae64f8767e348012d7932
In commit 28d337b[1], we advertized that the NEXT_MIN_LIBVIRT and
NEXT_MIN_QEMU_VERSION for "Stein" will be:
libvirt 3.0.0 and QEMU 2.8.0
Now that we are in the development cycle for "Stein", bump the
MIN_{LIBVIRT,QEMU}_VERSION to the above agreed-upon versions.
As part of this clean-up:
- Remove the _create_file_device() function and the calls to it; it is
a "no-op" when 'virtlogd' is available. As a result of this, in
_create_consoles_s390x(), this patch entirely removes the "sclplm"
serial console device — otherwise 'virtlogd', which is now always
available, will create a duplicate 'pty' devices ("sclplm" and
"sclp") pointing to the same log, which results in instance creation
failure; we don't want that.
- Remove the requirement for extra serial device (added in commit:
1f65925: "libvirt: virtlogd: use virtlogd for char devices"), that
"allows access to a Nova instance via `virsh console <guest>`" in
_create_pty_device() — it is not required. I also double-checked
with libvirt and QEMU developer Daniel Berrangé, who said (slightly
paraphrasing):
"Nova should not allow `virsh console` to guests behind its back
at all. And especially it should not care about `virsh console`
working with "tcp". The point of using "tcp" consoles in Nova
is that it provides tunneling via the Nova "serial console
server". You can only have 1 thing connected to a console at a
time — so if the Nova serial console is present, `virsh console`
can't be used anyway."
- The unit test noise is largely mechanical: remove the superflous
serial device, and lower the index of the devices by 1.
The following version constants (and corresponding tests), that are now
no longer required, will be removed in separate patches:
MIN_LIBVIRT_PARALLELS_SET_ADMIN_PASSWD,
MIN_LIBVIRT_POSTCOPY_VERSION, MIN_{LIBVIRT,QEMU}_LUKS_VERSION,
MIN_QEMU_FILE_BACKED_VERSION, MIN_LIBVIRT_PERF_VERSION
[1] http://git.openstack.org/cgit/openstack/nova/commit/?id=28d337b --
Pick next minimum libvirt / QEMU versions for "Stein"
Change-Id: I408baef12358a83921c4693b847a692f6c19e36f
Signed-off-by: Kashyap Chamarthy <kchamart@redhat.com>
This patch introduces a new API microversion which will be
used to alter the responses of ``GET /servers``, ``GET /servers/detail``,
``GET /servers/{server_id}`` and ``GET /os-services`` when a cell is
down to return minimal constructs with missing keys.
Implements blueprint handling-down-cell
Change-Id: Id9f12532897912b39093f63e9286540d9029edeb
This is to give the freedom to simulate down cells for each
individual cell targeted function calls.
Part of blueprint handling-down-cell
Change-Id: Ib5bfa1b6365fb78c7d3beb07c561c62ded5cb0e1
This patch specifically adds the returning of the partial
results in the ViewBuilder. Note that this will be enabled in
the microversion bump patch.
Related to blueprint handling-down-cell
Change-Id: Ie101678f8b9f0e624c84a355e6a7249dfe0530c4
The assertions on the user_id and project_id in the
fake_deserialize_context methods do not actually
cause tests to fail if they raise MismatchError
because oslo.messaging just swallows the exception
and logs the traceback. With enough of these getting
logged it will cause subunit parser failures in the
console output because the stream is too large.
This removes the fake method and just changes the
stub to be a lambda that returns self.context which
is what fake_deserialize_context was doing minus
the project_id/user_id assertions.
Change-Id: I26b201b410aa1d965dc7a6635c11c8b63b457a71
Partial-Bug: #1813147
The oslo_messaging._drivers.impl_fake.FakeExchangeManager._exchanges [1]
is a dict keyed by exchange name, "nova" for the nova services, and the
value is a FakeExchange that simulate a message bus for our tests.
It is basically a queue holding messages between FakeDriver instances
running in our rpc servers.
As FakeExchangeManager._exchanges is a class level variable it does not
get re-initialized between test cases that are running in the same
process.
So one test case can put an rpc message in the exchange that gets
delivered to the rpc server in a subsequent test case. This issue
made visible by the first patch set of the patch[2]
[1] 648ad56c86/oslo_messaging/_drivers/impl_fake.py (L149)
[2] https://review.openstack.org/#/c/635859/1
Change-Id: Ie60d783a970029371ec834aa26ca98252cdab83b