Drop support for most of the 'os-networks' REST APIs excluding those
that proxy through to neutron.
This API now returns a 410 response for the non-proxy routes.
Unit tests are removed for removed APIs and the functional API sample
tests are just asserting the 410 response now same. The latter are also
expanded to cover APIs that weren't previously tested.
The API sample docs are left intact since the API reference still builds
from those and can be considered more or less branchless, so people
looking at the API reference can apply it to older deployments of nova
before these APIs were removed.
Note: yes, the API samples are correct. It really is a useless API when
used with neutron.
Change-Id: I68bfa77a520382317fc490a4f6c12dd62fc6dcda
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
Not the first time we've done this [1]. Probably not the last.
[1] I5c99ff6b04ee97bac210a0d6762015225775c5ee
Change-Id: I9fc70df93af73b56ac9155d8d402b153d2af9f4e
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
These made things significantly less discoverable from the admin guide
and resulted in some duplication of links. Better to just flatten
things. Things are pretty much copy-pasted save for the removal of a
reference to the long-dead nova-objectstore service and the addition of
a TODO to provide overviews of other services.
Change-Id: Ibf2b6979318cf3f0a0519f66acbc279b2ce80968
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
This change simply extracts and slightly reorders the existing rescue
documentation from the reboot reference page.
Closes-Bug: #1852609
Change-Id: I4ce8874aa3e879e89ab5c7c76162561acbdea5c4
It doesn't really make sense to describe the "higher level"
configuration steps necessary for PCI passthrough before describing
things like BIOS configuration. Simply switch the ordering.
Change-Id: I4ea1d9a332d6585ce2c0d5a531fa3c4ad9c89482
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
Related-Bug: #1852727
While we do not have an automated fix for bug 1849479 this provides
a troubleshooting document for working around that issue where
allocations from a server that was evacuated from a down host need
to be cleaned up manually in order to delete the resource provider
and associated compute node/service.
In general this is also a useful guide for linking up the various
resources and terms in nova and how they are reflected in placement
with the relevant commands which is probably something we should
do more of in our docs.
Change-Id: I120e1ddd7946a371888bfc890b5979f2e19288cd
Related-Bug: #1829479
Add a section to the support matrix for image caching
(``has_imagecache`` virt driver capability).
Change-Id: I9147c5ea6b276b4fe18a981f4360844009bd3d95
Partial-Bug: #1847302
Blueprint image-precache-support added a conf section called
[image_cache], so it makes sense to move all the existing image
cache-related conf options into it.
Old:
[DEFAULT]image_cache_manager_interval
[DEFAULT]image_cache_subdirectory_name
[DEFAULT]remove_unused_base_images
[DEFAULT]remove_unused_original_minimum_age_seconds
[libvirt]remove_unused_resized_minimum_age_seconds
New:
[image_cache]manager_interval
[image_cache]subdirectory_name
[image_cache]remove_unused_base_images
[image_cache]remove_unused_original_minimum_age_seconds
[image_cache]remove_unused_resized_minimum_age_seconds
Change-Id: I3c49825ac0d70152b6c8ee4c8ca01546265f4b80
Partial-Bug: #1847302
A blocker migration was added in Train [1] to force
deployments to make sure they have completed the
services.uuid online migration (added in Pike). Now
that we're in Ussuri we can drop that online data
migration code.
Note that InstanceListWithServicesTestCase is removed
because the scenario is now invalid with the blocker
DB migration.
[1] I8927b8a4513dab242d34953d13dd2cc95393dc80
Change-Id: If77702f0c3212f904443f627037782f9ad7b3b55
This addresses some nits from that review related to
the tense in the docs and no longer valid code comments
in the resource tracker.
Change-Id: Idde7ef4e91d516b8f225118862e36feda4c8a9d4
In Train [1] we deprecated support for compute drivers
that did not implement the update_provider_tree method.
That compat code is now removed along with the get_inventory
method definition and (most) references to it.
As a result there are more things we can remove but those
will come in separate changes.
[1] I1eae47bce08f6292d38e893a2122289bcd6f4b58
Change-Id: Ib62ac0b692eb92a2ed364ec9f486ded05def39ad
When this patch [1] was introduced, it didn't take into consideration,
the updated/changed/modified parameters when using OSC vs nova CLI, so not
every option can be used in "openstack server create" which was used in "nova boot"
and vice versa. This bug would track reverting some of these incorrect commands usage.
For example- "nova boot --block device <params1>" can be translated as
"openstack server create --block-device-mapping <params2>" where params1 and
params2 are formatted differently (hence needs more than a simple search/replace)
[1] https://review.opendev.org/#/c/404623/
Related-To: https://review.opendev.org/#/c/404623/
Change-Id: I8e400da9445101b9ff5240511c56105e26e16e4c
Closes-Bug: #1851425
The mentality of being able to continuously deliver nova
has been around since the beginning with Rackspace public
cloud trying to CD openstack as close to master as possible.
This has implications for how code series are structured,
reviewed and merged. For the most part this seems to be tribal
knowledge and we don't have anything very obvious in the nova
docs about it, and not all projects in openstack necessarily
subscribe to this mentality anymore, or do so grudgingly, but
it's worth documenting it in nova while still applied here.
Change-Id: Ieff87dbd748318f1b7f879a136ff25081dac321e
The development policies section on code review was linking to the
generic openstack review guidelines but we have nova-specific
guidelines as well so this changes the policies page to link to the
nova code review guidelines, links the general guidelines into the
nova page, and also fixes a formatting issue in the nova code review
guidelines page.
Change-Id: I725570d0d737f18fe8b105dc8382c4abcfdef295
If we're booting from an existing volume but the instance is not being
created in a requested availability zone, and cross_az_attach=False,
we'll fail with a 400 since by default the volume is in the 'nova'
AZ and the instance does not have an AZ set - because one wasn't requested
and because it's not in a host aggregate yet.
This refactors that AZ validation during server create in the API to
do it before calling _validate_bdm so we get the pre-existing volumes
early and if cross_az_attach=False, we validate the volume zone(s) against
the instance AZ. If the [DEFAULT]/default_schedule_zone (for instances) is
not set and the volume AZ does not match the
[DEFAULT]/default_availability_zone then we put the volume AZ in the request
spec as if the user requested that AZ when creating the server.
Since this is a change in how cross_az_attach is used and how the instance
default AZ works when using BDMs for pre-existing volumes, the docs are
updated and a release note is added.
Note that not all of the API code paths are unit tested because the
functional test coverage does most of the heavy lifting for coverage.
Given the amount of unit tests that are impacted by this change, it is
pretty obvious that (1) many unit tests are mocking at too low a level and
(2) functional tests are better for validating these flows.
Closes-Bug: #1694844
Change-Id: Ib31ba2cbff0ebb22503172d8801b6e0c3d2aa68a
The info of Delete (Abort) on-going live migration is missing
in support matrix, it could be useful for users to consider
using this feature.
This patch adds it.
Change-Id: I2f917627fa451d20b1fd1ff35025481a4e525084
Closes-Bug: #1808902
This adds AggregateCacheNotification, related payload, and code in
conductor to emit this per-compute with progress information. This
also adds a "progress" phase to NotificationPhase, which allows for
start..progress..progress..end information for a single operation
(cache_images in this case).
Related to blueprint image-precache-support
Change-Id: I69ae26d4caf4b56ab2c4864455bfe9b5b736dbf3
This adds the functional notification sample test for the
aggregate.cache_images.start and aggregate.cache_images.end
versioned notifications.
I also added a comment to the docs builder code since it took
me a bit to figure out how to get the notification sample
linked into the docs, and for whatever reason figured that out
by looking through code rather than our nicely detailed docs
that already explain it.
Part of blueprint image-precache-support
Change-Id: I0869979a1b8a0966f0e7b49e5a5984f76d7d67cd
This adds a new microversion and support for requesting image pre-caching
on an aggregate.
Related to blueprint image-precache-support
Change-Id: I4ab96095106b38737ed355fcad07e758f8b5a9b0
In microversion 2.80, the ``GET /os-migrations`` API will have
optional ``user_id`` and ``project_id`` query parameters for
filtering migrations by user and/or project:
* GET /os-migrations?user_id=ef9d34b4-45d0-4530-871b-3fb535988394
* GET /os-migrations?project_id=011ee9f4-8f16-4c38-8633-a254d420fd54
* GET /os-migrations?user_id=ef9d34b4-45d0-4530-871b-3fb535988394&project_id=011ee9f4-8f16-4c38-8633-a254d420fd54
And expose the ``user_id`` and ``project_id`` fields in the following APIs:
* GET /os-migrations
* GET /servers/{server_id}/migrations
* GET /servers/{server_id}/migrations/{migration_id}
Co-Authored-By: Qiu Fossen <qiujunting>
Part of blueprint add-user-id-field-to-the-migrations-table
Change-Id: I7313d6cde1a5e1dc7dd6f3c0dff9f30bbf4bee2c
This is probably the most involved of all the changes and requires a
significant expansion of the NeutronFixture to mock floating IP
interactions. All the API samples were based off responses pulled from a
DevStack configuration using openstackclient and old versions of the
novaclient (where the 'floating-ip-*' commands were still present) in
debug mode.
Change-Id: Ib2f10a51bebd10cc69b78427b485aeac19f59141
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
We're going to want to use this for realistic API samples. The samples
we're using here were taken from a DevStack deployment based on pre-RC1
Train code so they should be fairly reflective of what you'd see in a
real deployment.
Note that this effectively undoes a lot of the changes first introduced
in Ibbee7fd11c1aa254e399d302adbae69126e98262, particularly around the
responses for instances in a down cell, where we previously changed
things so a 'security_groups' field was present in the response. This
is okay since we're not creating interfaces and therefore don't expect
to have security groups present.
Change-Id: I3c94b61fc323fefbd1c8790c4a2f60cada29e86f
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
This is a follow up to [1]. The user docs home page has a link
to the admin AZ guide but not a direct link to the user AZ guide
so that is added here.
[1] https://review.opendev.org/#/c/667133/10/doc/source/user/index.rst@75
Change-Id: I4acb120d2e347a43abc584107c7a19bb422af384
These were missed in change If847b0085dbfb4c813d4a8d14d99346f8252bc19.
Change-Id: Iad18f355a20261313ddb3dafd302ed66ebca64bc
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
Stephen Finucane