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
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
Takashi NATSUME