The 'binary' parameter has been changed to the 'source'
since I95b5b0826190d396efe7bfc017f6081a6356da65.
But the notification document has not been updated yet.
Replace the 'binary' parameter with the 'source' parameter.
Change-Id: I141c90ac27d16f2e9c033bcd2f95ac08904a2f52
Closes-Bug: #1836005
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
This provides a link to gibi's talk from the Train summit
on versioned notifications in to the reference docs.
Change-Id: I5d0c1fb675bdf2cae699efd733048663e5828699
Based on bug 1823104 it's clear we should have some
explicit wording in the notification reference docs
about what not to include in versioned notification
payloads, so this change attempts to start that with
the most obvious thing - don't expose access credentials
to the nova deployment.
This also adds a reminder to think about what is being
added / mirrored from internal objects and determine if
consumers really need it and if they aren't asking, opt
to not including it until requested.
Change-Id: I326aa39d963091282a5d0b70ba222abfe8ccfdac
Related-Bug: #1823104
1 typo fixes
2 use :oslo.config:option: elements for nova conf options
3 change '`' to '``' where applicable
Change-Id: Icfebf894185fc83f5fa77e8e10a42ba9dbb37755
This ensures we have version-specific references to other projects [1].
Note that this doesn't mean the URLs are actually valid - we need to do
more work (linkcheck?) here, but it's an improvement nonetheless.
[1] https://docs.openstack.org/openstackdocstheme/latest/#external-link-helper
Change-Id: Ifb99e727110c4904a85bc4a13366c2cae300b8df
This adds information to the "notification_format" config
option help and notifications docs on how to disable notifications.
While updating the config option help text, a stale reference
to Pike is removed.
Change-Id: I736025a0a88fc969831558805687b642da8cd365
Closes-Bug: #1761405
The example versioned notifications don't have any indication of
which release they are available in, and since people can link to
the 'latest' docs, like in I51d0deffc4f42ff2722a8d21aa6b8c8008c62723,
it's important to note that the samples in the latest docs might not
be in the version of nova one is actually using, e.g. ocata or pike.
So this adds a note that people should be aware of that before
relying on some versioned notification.
Change-Id: I2f7db424f0938667895b51f45ea60862a32e22c1
Based on the description of the notify_on_api_faults config option [1]
and the code that uses it [2] nova sends and api.fault notification
if the nova-api service encounters an unhandle exception.
There is a FaultWrapper class [3] added to the pipeline of the REST
request which catches every exception and calls the notification sending.
Based on some debugging in devstack this FaultWrapper never catches any
exception. Every REST API method is decorated with expected_errors
decorator [5] which as a last resort translate the unexpected exception
to HTTPInternalServerError. In the wsgi stack the actual REST api call is
guarded with ResourceExceptionHandler context manager [7] which translates
HTTPException to a Fault [8]. Then Fault is catched and translated to
the REST response [7]. This way the exception never propagates back to
the FaultWrapper and therefore the api.fault notification is never emitted.
Based on the git history of the expected_errors decorator this notification
was never emitted for v2.1 API and as the v2.0 API now supported with the
same codebase than v2.1 it is not emitted for v2.0 calls either. As nobody
reported a bug I assume that nobody tried to use this notification for a very
long time. Therefore instead of fixing this bug this patch propses to remove
the dead code.
See a bit more detailed description on the ML [9].
[1] 0aeaa2bce8/nova/conf/notifications.py (L49)
[2] 0aeaa2bce8/nova/notifications/base.py (L84)
[3] 0aeaa2bce8/nova/api/openstack/__init__.py (L78)
[5] 0aeaa2bce8/nova/api/openstack/extensions.py (L325)
[7] 0aeaa2bce8/nova/api/openstack/wsgi.py (L637)
[8] 0aeaa2bce8/nova/api/openstack/wsgi.py (L418)
[9] http://lists.openstack.org/pipermail/openstack-dev/2017-June/118639.html
Change-Id: I608b6ebdc69d31eb2a11ac6479fa4f2e8c20f7d1
Closes-Bug: #1699115
Notifications are essentially another API for end users, but
it can be hard to find the list of existing notifications or
their samples which are buried deep down via contributors >
technical reference deep dive > notitfications. If I'm an
end user, I'd like to just see them in the same set of links
on the main page as the API, under the "For End Users" section.
Change-Id: If3ca21b080d06a291ed27c9bcd84a566164c3b70
During the implementation of I1c8c038078bbe1a5914a92d44b3e977287294a88
we realized that the inheritance used in the notification payload
classes has some drawbacks. When we need to introduce new leaf classes
the content of the nova.obj_name field will change in the emited
payload. This should be avoided if possible. If this cannot be avoided
and the only change is the renaming then the version of the new
payload shall be the same as the old payload was before the rename.
If the renaming involves any other changes on the payload (e.g. adding
new fields) then the version of the new payload shall be higher than
the old payload was.
Change-Id: Ie8c9317892f5593d473067d5dfc300a7e98795c5
Per the spec [1]:
reference/ – any reference information associated with a project that
is not covered by one of the above categories. Library projects should
place their automatically generated class documentation here.
There are a couple of documents that focus on nova internals, but won't
necessarily be applicable to user. These are moved here.
[1] specs.openstack.org/openstack/docs-specs/specs/pike/os-manuals-migration
Change-Id: I94614c2383329e1fbed60d9c5aca3fab5170ef8f
