Changes in svg:
- schema with nova-network is removed and one with Neutron is made as default
- Placement service is added to a party
- titles and arrows are aligned
Change-Id: If7e4a0b92c8713dabcb16a5e7820fbf479d82917
extensions, stevedore and extensions config options are gone
and plain router is introduced in Pike.
Also this documents was little bit confusing about current and
old state of APIs.
This commit makes it more clear and reflect the current API state
and also describe the evolution of APIs.
Change-Id: I6522100a78241400b1ea059a39a32c259fe6ab90
Per the spec [1]:
user/ – end-user content such as concept guides, advice, tutorials,
step-by-step instructions for using the CLI to perform specific tasks,
etc.
The remaining content all ends up in here.
[1] specs.openstack.org/openstack/docs-specs/specs/pike/os-manuals-migration
Change-Id: I480eee9cd7568efe2f76dd185004774588eb4a99
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
Per the spec [1]:
contributor/ – anything related to contributing to the project or how
the team is managed. Applies to some of the current content under
/developer, we are changing the name to emphasize that not all
contributors are developers and sometimes developers are users but not
contributors.
We currently have a handful of docs that focus on the "how to develop or
contribute" aspects of nova, and these are moved. Docs that focus on
architecture or design decisions for nova are not moved, as these will
go into 'reference'.
A TODO is added to the former 'api_plugins' document as it's mega
out-of-date and needs some serious work.
[1] specs.openstack.org/openstack/docs-specs/specs/pike/os-manuals-migration
Change-Id: Iad770688b4eafeb9caa710b4398b02d80a017a70
Add in feature_classification.ini that makes use of new sphinx
extension feature_matrix. While it is loosely based on the
support_matrix extension, longer term this extension will live
outside the Nova tree. As such, this has been created as a new
separate sphinx plugin.
The matrix has links to wiki page for the CI in the header of the
summary matrix. This is called a target.
Also, there are links to admin docs, API docs, and tempest test uuids
added into the feature details. An option is added to ensure these are
always present in the prototype matrix.
A maturity status is added to be clear about the level of maturity
of each feature. When in maturity mode, this is added into the summary
table in place of the status. There is also some formating for the
different maturity levels.
blueprint feature-classification
Change-Id: Ib5895e8de901f1a282d0f5c0ecb811ff8b451497
Some features could be made clearer if the CLI commands which are
related to that feature are listed. This patch set allows to set
CLI commands per feature.
This is an interim solution until the new feature classification
system is established.
Change-Id: If599627187080a8349811f50f6561e9efbc35138
When a new feature gets added to the hypervisor support matrix it
was not possible to state that the hypervisor did not make a support
statement yet. You had to choose between "complete", "partial" and
"missing" wich could be missleading.
This change set adds the status "unknown" which could make the
statements more precise.
Change-Id: If94fc772796742de88af5893839945834b9d3eb6
Add document to replace / obsolete the giant table on
https://wiki.openstack.org/wiki/HypervisorSupportMatrix
This initial draft is a fairly straightforward conversion of
that table. Over time, it needs much work to improve the coverage
of API operations and and coverage of important configuration
information that users will care about.
It is using the .ini file syntax in order to record the data in
an easily machine parsable format, while remaining human friendly
by avoiding the syntax heavy approach of XML / JSON / YAML
An extension is registered with sphinx that can convert the
.ini file content into docutils content that then gets rendered
into the developer docs, linked from the index page
Change-Id: I4d3db4bce5737dba30a026a11083a9ea64459cd4
Use the new oslo.sphinx version of the OpenStack doc
theme instead of copying it into this repo.
blueprint oslo.sphinx
Signed-off-by: Doug Hellmann <doug.hellmann@dreamhost.com>
Change-Id: I0bd91f7bb43f97b99051fed65b75fc05d5149cc8
Closes bug 902846.
Turns out that without providing a default css file,
docutils tries to pull one in from a location using
very bad path logic. Glance was providing the css file
explicitly and it worked, so I just copied them.
Change-Id: I6cc9d0ca148149637104c27f6c020030bdbcfe18
Andrey Volkov