Per change I97215e94efdd8c05045872fb9ba7d2089dc6efb8, nova
does not perform version discovery or try to deal with backlevel
placement versions, and the upgrade docs say that placement needs
to be upgraded before upgrading any nova services. Because of
this assertion, we can remove the per-release nova-scheduler-specific
note in the placement upgrade notes for Rocky because while it's
accurate for the nova-scheduler service, it might not be accurate
for the nova-api, nova-conductor or nova-compute services which
also use placement. So the best guidance is to just globally say
that placement must be upgraded before *any* nova services, which
our upgrade doc already says.
Change-Id: I8bf6ab049f15ad24a5fbf0557bd0cd8652101901
This change provides a small number of updates to the placement user and
contributor documentation to reflect some of the things that have
changed recently. This is by no means complete, but is an improvement
over what was there.
Partial-Bug: #1778227
Change-Id: Ia348cd3c99b1a5104e15595fdebc83e1ca582a98
Change I496e8d64907fdcb0e2da255725aed1fc529725f2 made nova-scheduler
require placement >= 1.25 so this change updates the minimum required
version checked in the nova-status upgrade check command along with the
upgrade docs.
related to blueprint: granular-resource-requests
Change-Id: I0a17ee362461a8ae2113804687799bb9d9216110
This patch is the first step in syncing the nova host aggregate
information with the placement service. The scheduler report client gets
a couple new public methods -- aggregate_add_host() and
aggregate_remove_host(). Both of these methods do **NOT** impact the
provider tree cache that the scheduler reportclient keeps when
instantiated inside the compute resource tracker.
Instead, these two new reportclient methods look up a resource provider
by *name* (not UUID) since that is what is supplied by the
os-aggregates Compute API when adding or removing a "host" to/from a
nova host aggregate.
Change-Id: Ibd7aa4f8c4ea787774becece324d9051521c44b6
blueprint: placement-mirror-host-aggregates
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
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
This adds a mention of the nova-scheduler service requiring
placement 1.17 and also links to the placement upgrade notes
from the more general upgrade notes, since we are now firmly
in a place where placement needs to be upgraded before nova.
Since we consider placement global, this removes the 1.14
note about nova-compute since we assume that if you're going
to upgrade placement to get 1.17 for the scheduler, and control
services should be upgraded before computes, then the computes
are going to get a new enough placement service automatically.
Change-Id: I06937c7642dca4a1932cbbf46569acc9c58e44a6
With change I2f367b06e683ed7c815dd9e0536a46e5f0a27e6c, nova-compute
now unconditionally requires Placement 1.14 to be available (the
client side code doesn't check to see if 1.14 is available before
trying to use it).
This change updates the nova-status check for the minimum required
version of Placement and also starts the "Queens" section of the
Placement upgrade notes docs.
Change-Id: I37415e384d375bc9b548a0223f787a9236286bb0
The web-server-deployment section of placement.rst has been updated
to provide additional links to information and reflect the fact that
placement is now using uwsgi and mod_proxy_uwsgi in devstack. This
does not provide a full set of installations instructions. This is
somewhat intentional:
* there are many ways to deploy a wsgi application and we'd like the
packagers and deployers to choose a way that works best for them,
not impose one, and there's no way for us to document them all. It
is better to point to resources that explain some of the options
and allow people to inform themselves so they can make informed
choices
* we're no longer that keen on the mod_wsgi, but it tends to be the
easiest to document (fewer moving parts)
* the uwsgi+systemd method in devstack, while great, is abstracted
enough that the moving parts are not entirely visible and is one
of several ways for that scenario
Change-Id: Ief07c313e012df63558de632047258e8e11736c1
Related-Bug: #1692375
Now that we have a placement api-ref getting published, we
should link to it like we do for the compute api-ref. This
also links in the placement microversion history for consistency.
Change-Id: Id0c70486c5a72a4d6794d80d350a45a5f356ca37
This provides a more detailed, but still high level, explanation
of how the FilterScheduler is using allocation candidates to pick
hosts during scheduling, and how the allocations are handled during
a move operation, including a resize to the same host.
Ideally this content will live somewhere else in the devref, or
would be updated in the spec for blueprint placement-claims, but
for now this should suffice for Pike release notes that can point
at this upgrade doc.
Change-Id: I274c684f829bc310ebb17faabf498d36f4ceea0c
Per the spec [1]:
user/ – end-user content such as concept guides, advice, tutorials,
step-by-step instructions for using the CLI to perform specific tasks,
etc.
The remaining content all ends up in here.
[1] specs.openstack.org/openstack/docs-specs/specs/pike/os-manuals-migration
Change-Id: I480eee9cd7568efe2f76dd185004774588eb4a99
Matt Riedemann