The output of 'nova-manage cell_v2 list_cells' command
has been modified since Idb306e4f854957fd2ded9ae061fc27f0ef768fc0 and
I96a6d5e59d33c65314fc187c0286ce3408d30bdc.
Fix the output of the command in the install documents.
Change-Id: I45d0e2ee1ff182347345af46f9a388f2884ba6cd
Closes-Bug: #1833647
- This change extends the VideoModel field object to allow 3 new values
(virtio, gop, none)
- This change makes the libvirt driver use ALL tuple from the
nova.fields.VideoModel object instead of declaring a second
tuple inline for validation.
- This change allows the virtio video model to now be used
for all architectures when explicitly requested via the
hw_video_model image metadata property
- This change introduces unit tests and a release note
for the new capablities.
Change-Id: I2830ccfc81cfa9654cfeac7ad5effc294f523552
Implements: blueprint libvirt-video-device-models
The virt driver FakeDriver used in both the functional and in the unit
test used a global state to configure the host and node names the driver
reports. This was hard to use when more then one compute service is started.
Also global state is dangerous.
It turned out that only a set of unit tests are using multiple nodes per
compute the rest of the tests can simply use host=<hostname>,
nodes=[<hostname>] setup.
So this removes the global state.
Change-Id: I2cf2fcbaebc706f897ce5dfbff47d32117064f9c
Turns out we've a *lot* of disparate metadata systems. Attempt to both
link them somewhat through extensive cross-referencing and extract out
deployment-specific stuff from user-facing docs. Lots of changes here,
but in summary:
- Split out admin-focused content from the metadata API, config drive,
user data and vendordata docs.
- Merge the config drive, metadata service, vendordata and user-data
user docs, which are mostly talking about the same thing and are
fairly barren without the deployment components
- Make use of various oslo.config and Sphinx roles
Side note: I miss when we have tech writers to do this stuff for us :(
Change-Id: I4fb2b628bd93358a752e2397ae353221758e2984
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
The --before option to nova manage db purge and archive_deleted_rows
accepts a string to be parsed by dateutils.parser.parse() with
fuzzy=True. This is fairly forgiving, but doesn't handle e.g. "now - 1
day". This commit adds some clarification to the help strings, and some
examples to the docs.
Change-Id: Ib218b971784573fce16b6be4b79e0bf948371954
This is a follow up to b129511050e3bcedd0079041ecdb8d156baa67eb
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
This hasn't been needed since we moved console authentication to the
database in Rocky.
Part of blueprint remove-consoleauth
Change-Id: Ie5e7d70f9d6af77edd22756128937f06d0b961a9
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
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] 51f9f0098d
[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
The description at the start of the docs is actually pre-pike
behavior replaced by the first "future plans" item which was
the counting quotas effort in pike. This change re-words the
main description to talk about counting quotas at a high level,
links in more of the relevant APIs, links to the config options
correctly, drops the future plan about counting quotas (since it
is no longer the future) and fleshes out a little blurb about
hierarchical quotas by linking to the unified limits spec.
Change-Id: I559938f69c9b462a9b0baeb5d1d4d915f893273e
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
ZeroMQ driver is deprecated, as per the Dublin 2018 PTG decision:
http://lists.openstack.org/pipermail/openstack-dev/2018-March/128055.html
This change simply replaces the zeromq mention with a link to the
other oslo.messaging drivers.
Co-Authored-By: Matt Riedemann <mriedem.os@gmail.com>
Change-Id: I0c8d488c1daecc71d7d2817ffb4ae10727771d19
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