This is a follow up to b129511050
which changes the code block in the docs to python and also
cleans up some of the NumInstancesFilter documentation, specifically
removing wording around "running" instances because the filter
does not care about state, only the number of instances reported
against a host - they could be stopped/paused/etc.
Change-Id: I7cdf79f21415fbf799fa5ad586f1b8063afed272
Since blueprint return-alternate-hosts in Queens, the scheduler
returns a primary selected host and some alternate hosts based
on the max_attempts config option. The only reschedules we have
are during server create and resize/cold migrate. The list of
alternative hosts are passed down from conductor through compute
and back to conductor on reschedule and if conductor gets a list
of alternate hosts on reschedule it will not call the scheduler
again. This means the RetryFilter is effectively useless now since
it shouldn't ever filter out hosts on the first schedule attempt
and because we're using alternates for reschedules, we shouldn't
go back to the scheduler on a reschedule. As a result this change
deprecates the RetryFilter and removes it from the default list
of enabled filters.
Change-Id: Ic0a03e89903bf925638fa26cca3dac7db710dca3
This fixes a couple of places in the admin scheduler config
docs that were listing out the enabled_filters default value
incorrectly because the ComputeFilter was missing. Rather than
try to keep the docs mirrored with the actual default value,
this change references the config option in one spot and avoids
listing the defaults in another.
Change-Id: I837aefcd37556a7b66b523529c5ca1f3dee8ac7f
Closes-Bug: #1833120
We're going to remove all the code, but first, remove the docs.
Part of blueprint remove-consoleauth
Change-Id: Ie96e18ea7762b93b4116b35d7ebcfcbe53c55527
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
The RamFilter has deprecated since the stein release. We can show
another simple filter class here.
Change-Id: I15a935e80f6656c96c1e208746af1c89bf37b670
Starting in noVNC v1.1.0, the token query parameter is no longer
forwarded via cookie [1]. We must instead use the 'path' query
parameter to pass the token through to the websocketproxy [2].
This means that if someone deploys noVNC v1.1.0, VNC consoles will
break in nova because the code is relying on the cookie functionality
that v1.1.0 removed.
This modifies the ConsoleAuthToken.access_url property to include the
'path' query parameter as part of the returned access_url that the
client will use to call the console proxy service.
This change is backward compatible with noVNC < v1.1.0. The 'path' query
parameter is a long supported feature in noVNC.
Co-Authored-By: melanie witt <melwittt@gmail.com>
Closes-Bug: #1822676
[1] https://github.com/novnc/noVNC/commit/51f9f0098d306bbc67cc8e02ae547921b6f6585c
[2] https://github.com/novnc/noVNC/pull/1220
Change-Id: I2ddf0f4d768b698e980594dd67206464a9cea37b
When the 'nova-manage cellv2 discover_hosts' command is run in parallel
during a deployment, it results in simultaneous attempts to map the
same compute or service hosts at the same time, resulting in
tracebacks:
"DBDuplicateEntry: (pymysql.err.IntegrityError) (1062, u\"Duplicate
entry 'compute-0.localdomain' for key 'uniq_host_mappings0host'\")
[SQL: u'INSERT INTO host_mappings (created_at, updated_at, cell_id,
host) VALUES (%(created_at)s, %(updated_at)s, %(cell_id)s,
%(host)s)'] [parameters: {'host': u'compute-0.localdomain',
%'cell_id': 5, 'created_at': datetime.datetime(2019, 4, 10, 15, 20,
%50, 527925), 'updated_at': None}]
This adds more information to the command help and adds a warning
message when duplicate host mappings are detected with guidance about
how to run the command. The command will return 2 if a duplicate host
mapping is encountered and the documentation is updated to explain
this.
This also adds a warning to the scheduler periodic task to recommend
enabling the periodic on only one scheduler to prevent collisions.
We choose to warn and stop instead of ignoring DBDuplicateEntry because
there could potentially be a large number of parallel tasks competing
to insert duplicate records where only one can succeed. If we ignore
and continue to the next record, the large number of tasks will
repeatedly collide in a tight loop until all get through the entire
list of compute hosts that are being mapped. So we instead stop the
colliding task and emit a message.
Closes-Bug: #1824445
Change-Id: Ia7718ce099294e94309103feb9cc2397ff8f5188
Replace 'is comprised of' with 'comprises'
because the 'is comprised of' is disputed use.
Change-Id: If66d2e4583b00102d52635457f3c3f8c2adee1be
Closes-Bug: #1831309
This removes the old reference to the nova-manage
command to refresh quota usage which no longer
applies since we started counting quotas in the
Pike release.
This replaces with a reference to the down-cell
known issue for counting quotas.
Change-Id: I2765f3ca3dc95345d4e4c4db43ac3dff4a509259
In May 2019, four new microprocessor security flaws, known as "MDS"
(Microarchitectural Data Sampling) have been discovered. These flaws
affect unpatched Nova Compute nodes and instances running on Intel
x86_64 CPUs. The said security flaws are also referred to as "RIDL"
(Rogue In-Flight Data Load) and "Fallout".
Refer to the following pages for further details:
- https://access.redhat.com/security/vulnerabilities/mds
- https://mdsattacks.com/
- https://zombieloadattack.com/
* * *
If we're adding the guide for "MDS" flaws, then it begs the
question: "What about mitigation guides for previous vulnerabilities?"
Two points:
(a) Write the mitigation document for rest of the previous
vulnerabilities too, for completeness' sake. (In April 2018 I wrote
this doc[1] for Meltdown — polish it and submit it. Parts of that
document's content is already incorporated into the help text for
the config attribute `cpu_model_extra_flags`.)
(b) For now, we can live with the cliché, "something is better than
nothing"; we'll add the other docs "when we get to it". Meanwhile,
operators get mitigation details from various other places —
processor vendors, Linux distributions, etc.
[1] https://kashyapc.fedorapeople.org/Reducing-OpenStack-Guest-Perf-Impact-from-Meltdown.txt
Change-Id: I1bb472c3438cc9a91945999d2350b2c59fa6a1f3
Signed-off-by: Kashyap Chamarthy <kchamart@redhat.com>
The default config `both` means that both the legacy and the versioned
notifications are emitted. This was selected as default in the past when
we thought that this will help the adoption of the versioned interface
while we worked on to make that new interface in feature parity with the
legacy. Even though the versioned notification interface is in feature
parity with the legacy interface since Stein the projects consuming nova
notifications do not have the resources to switch to the new interface.
In the other hand having `both` as a default in an environtment where
only the legacy notifications are consumed causes performance issues in
the message bus hence the bug #1805659.
The original plan was that we set the default to `versioned` when the
interface reaches feature parity but as major consumers are not ready
to switch we cannot do that.
So the only option left is to set the default to `unversioned`.
Related devstack patch: https://review.opendev.org/#/c/662849/
Closes-Bug: #1805659
Change-Id: I72faa356afffb7a079a9ce86fed1b463773a0507
reno doesn't have stable branches and doesn't version its documentation.
There's no point versioning our links to same.
Change-Id: Id782d3b11715bc3211e7952fb01b42a659d06e36
Closes-Bug: #1830926
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
This provides a link to gibi's talk from the Train summit
on versioned notifications in to the reference docs.
Change-Id: I5d0c1fb675bdf2cae699efd733048663e5828699
Add a parameter to limit the archival of deleted rows by date. That is,
only rows related to instances deleted before provided date will be
archived.
This option works together with --max_rows, if both are specified both
will take effect.
Closes-Bug: #1751192
Change-Id: I408c22d8eada0518ec5d685213f250e8e3dae76e
Implements: blueprint nova-archive-before
All the tox targets require postgres' pg_config to be runnable,
so that always needs installing from brew. Add that and a hint
about python3 from brew and tox from that python's pip.
Change-Id: Id26700bdea5443cb266b166b7b35eef3c8315451
This adds the missing "prefilter" stage to the description of the
scheduling process, and adds information about the image type
filter.
Related to blueprint request-filter-image-types
Change-Id: I07eef048cf2c85a3fdb8adbe38e362878e4e177e
The compute API has required cinder API >= 3.44 since Queens [1] for
working with the volume attachments API as part of the wider
volume multi-attach support.
In order to start removing the compatibility code in the compute API
this change adds an upgrade check for the minimum required cinder API
version (3.44).
[1] Ifc01dbf98545104c998ab96f65ff8623a6db0f28
Change-Id: Ic9d1fb364e06e08250c7c5d7d4bdb956cb60e678
This finalizes the removal of the placement code from nova.
This change primarily removes code and makes fixes to cmd,
test and migration tooling to adapt to the removal.
Placement tests and documention were already removed in
early patches.
A database migration that calls
consumer_obj.create_incomplete_consumers in nova-manage has been
removed.
A functional test which confirms the default incomplete
consumer user and project id has been changes so its its use of
conf.placement.incomplete_* (now removed) is replaced with a
constant. The placement server, running in the functional
test, provides its own config.
placement-related configuration is updated to only register those
opts which are relevant on the nova side. This mostly means
ksa-related opts. placement-database configuration is removed
from nova/conf/database.
tox.ini is updated to remove the group_regex required by the
placement gabbi tests. This should probably have gone when the
placement functional tests went, but was overlooked.
A release note is added which describes that this is cleanup,
the main action already happened, but points people to the
nova to placement upgrade instructions in case they haven't
done it yet.
Change-Id: I4181f39dea7eb10b84e6f5057938767b3e422aff
Zuul