In preparation for stein, use 'endpoint' instead of 'ironic_url'
when calling get_client in order to remove the following warning:
WARNING ironicclient.client The argument "ironic_url" passed to
get_client is deprecated and will be removed in Stein release,
please use "endpoint" instead.
For reference:
In the python-ironicclient code, in the ironicclient/client.py#L24
TODO(vdrok): remove in Stein
[...]
('ironic_url',): 'endpoint',
Introduced in commit:
https://github.com/openstack/python-ironicclient/commit/58c39b7a80583dd54165cf292ae5dc621e9da361
Change-Id: I1b3ce1955622c40b780c0b15ec7e09be3e8ace72
As nova extensions has been deprecated already and goal is to
merge all scattered code into main controller side.
Currently schema and request/response extended code are there
among all extensions.
This commit merges the image_size extension response into image
view builder.
Partially implements: blueprint api-extensions-merge-stein
Change-Id: Ifca9d9b766c87d4e1107e9be07223f8d4a0d6794
Change Ia69fabce8e7fd7de101e291fe133c6f5f5f7056a sets the
ComputeNode.uuid to whatever the virt driver reports if the
virt driver reports a uuid, like in the case of ironic.
However, that breaks upgrades for any pre-existing compute
node records which have a random uuid since ComputeNode.uuid
is a read-only field once set.
This change simply ignores the uuid from the virt driver
resources dict if the ComputeNode.uuid is already set.
The bug actually shows up in the ironic grenade CI job
logs in stable/rocky but didn't fail the nova-compute startup
because ComputeManager._update_available_resource_for_node()
catches and just logs the error, but it doesn't kill the service.
Change-Id: Id02f501feefca358d36f39b24d426537685e425c
Closes-Bug: #1798172
If transport_url or connection are unset in config, we will fail to format
even non-templated cell mapping URLs due to an overly specific check in the
format routines. This fixes it by always bailing on templating if the config
is unset, and keeping the error message if we were unable to format a
template as a result.
Change-Id: I760580b8e6594be2bee99a5b825a690b07ab9deb
Closes-Bug: #1798158
If there are multiple consumers having allocations to the same
resource provider, with different classes, it will attempt
multiple INSERTs with the same consumer_id which is not allowed
because of the database constraints.
This patch adds a simple GROUP BY in order to ensure that the
database server only provides us with unique values to avoid
trying to INSERT duplicate values.
Change-Id: I1acba5e65cd562472f29e354c6077f82844fa87d
Closes-Bug: #1798163
Change Icae5038190ab8c7bbdb38d54ae909fcbf9048912 in Rocky
attempts to online migrate missing consumers table records
when listing allocations for a given resource provider. The
problem is when it's doing an insert-from-select, it's not
handling multiple allocations on the same provider for the
same consumer, like you'd have with a compute instance that
has VCPU, MEMORY_MB and DISK_GB allocations against a single
compute node resource provider. As a result, the insert
statement has duplicate consumer IDs in it which results in
a unique constraint violation.
The existing tests never caught this because they tested with
3 unique consumers with a single allocation each.
The functional test added here hits both online data migration
routines: via the API when listing allocations for a resource
provider and the direct online data migration CLI.
Change-Id: Iba56aa6b227b6455d2437e4fabcd296b1b0f06ee
Related-Bug: #1798163
When online_data_migrations raise exceptions, nova/cinder-manage catches
the exceptions, prints fairly useless "something didn't work" messages,
and moves on. Two issues:
1) The user(/admin) has no way to see what actually failed (exception
detail is not logged)
2) The command returns exit status 0, as if all possible migrations have
been completed successfully - this can cause failures to get missed,
especially if automated
This change adds logging of the exceptions, and introduces a new exit
status of 2, which indicates that no updates took effect in the last
batch attempt, but some are (still) failing, which requires intervention.
Change-Id: Ib684091af0b19e62396f6becc78c656c49a60504
Closes-Bug: #1796192
Previously, if the call to Cinder in _post_live_migration failed, the
exception went unhandled and prevented us from calling
post_live_migration_at_destination - which is where we set instance
host and task state. This left the system in an inconsistent state,
with the instance actually running on the destination, but
with instance.host still set to the source. This patch simply wraps
the Cinder API calls in a try/except, and logs the exception instead
of blowing up. While "dumb", this has the virtue of being simple and
minimizing potential side effects. A comprehensive refactoring of
when, where and how we set instance host and task state to try to
guarantee consistency is left as a TODO.
Partial-bug: 1628606
Change-Id: Icb0bdaf454935b3713c35339394d260b33520de5
This adds a few more things to the upgrade checks
reference docs after getting questions about it
during the Stein release goal implementation from
other project teams:
1. Notes the high level set of steps for upgrading
nova in grenade and where nova-status fits into
that sequence.
2. Links to the oslo.upgradecheck library which
didn't exist when the original document was
written.
3. Adds a FAQs section with Q&A for several things
that have come up during the Stein release goal.
Change-Id: I990e5dbe563fa342f7481c3720445b924447ad54
Story: 2003657
Add microversion 2.67 to REST API Version History, it is used as an
index by novaclient's release note, and rename the "test_block_device"
test case
"test_from_api_invalid_oneof_image_id_or_destination_local_mapping" to
"test_from_api_invalid_image_to_destination_local_mapping", mentioned by
melwitt.
Depends-On: https://review.openstack.org/#/c/606398/
Part of blueprint boot-instance-specific-storage-backend
Change-Id: Ic6d562947f445c6f6cabd69484bc85b7aea88e48
This commit migrate the legacy-tempest-dsvm-nova-v20-api
job to zullv3 native with new job - tempest-nova-v2-api
Change-Id: I6915b7deca20eabb88c231b287586c64cdcf3646
If the driver.block_stats() method returns None, like the
libvirt driver will if the guest is gone during an evacuate,
we'll get a NoneType error trying to unpack the return value
from the driver. Instead, simply return as if the driver
raised NotImplementedError.
Since handling None is changing the contract on the virt
driver API, the docstring is updated to explain the acceptable
return values of the driver method.
Change-Id: I98a2785c07f7af02ad83650c72d9e1868290ece4
Closes-Bug: #1796981
With moving away from required milestone releases, the version numbers
calculated by PBR on the master branch will not work for those testing
upgrades from the last stable release. More details can be found in the
mailing list post here:
http://lists.openstack.org/pipermail/openstack-dev/2018-October/135706.html
This is an empty commit that will cause PBR to increment its calculated
version to get around this.
PBR will see the following which will cause it to increment the version:
Sem-Ver: feature
Please merge this patch as soon as possible to support those testing
upgrades.
Change-Id: I3ef10a9afe61c95d4622cbc4713b455525fbd952
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
The legacy job legacy-tempest-dsvm-neutron-pg-full is now named
tempest-pg-full - using the new tempest and Zuul v3 frameworks.
Change experimental job to use new job.
Change-Id: I10865188e4a43b2399f647124dfff8ade40b875c
Depends-On: https://review.openstack.org/609530
Add a new microversion 2.67 to support specify ``volume_type``
when boot instances.
Part of bp boot-instance-specific-storage-backend
Change-Id: I13102243f7ce36a5d44c1790f3a633703373ebf7
This adds validation in the compute API for when a
block_device_mapping_v2 request specifies a volume_type. Note that
this is all noop code right now since users cannot specify that field in
the API until the microversion is added which enables that feature.
In other words, this is just plumbing.
Part of bp boot-instance-specific-storage-backend
Change-Id: I45bd42908d44a0f05e1231febab926b23232b57b
Add support specifying ``volume_type`` to storage backend
when booting instance in compute version 36.
bp: boot-instance-specific-storage-backend
Change-Id: Icc301230fe7c8e3ebbbcc7f4a807e562db7f93e3
In Rocky, we deprecated the nova-consoleauth service but there were
unconditional calls to nova-consoleauth in the compute/api, which
made it impossible to avoid running the nova-consoleauth service.
This adds conditional checks to call nova-consoleauth only if the
[workarounds]enable_consoleauth configuration option is True. The
option defaults to False because the default console token auth TTL
is 10 minutes and only operators who have configured much longer TTL
or otherwise wish to avoid resetting all consoles at upgrade time
need to use the option.
This also updates the /os-console-auth-tokens/{console_token} API to
use nova-consoleauth only if the [workarounds] option is enabled. This
had to be done in the same change because the conditional checks in
the compute/api code caused the /os-console-auth-tokens API functional
tests to fail to find token authorizations in nova-consoleauth.
Closes-Bug: #1788470
Closes-Bug: #1795982
Change-Id: Iff6020f1a10afc476864f979faf251ef5a1a6184
As nova extensions has been deprecated already and goal is to
merge all scattered code into main controller side.
Currently schema and request/response extended code are there
among all extensions.
This commit merge the used_limits extension resposne into limit
view builder.
Partially implements: blueprint api-extensions-merge-stein
Change-Id: I76e02214e958a55b6de8033243b46b259949e5ac
Daniel Abad