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
Matt Riedemann