Fix ironic-specs repo doc builds
Since the documentation PTI job config was implemented in zuul, the local docs builds no longer matched the builds performed by zuul in terms of treating warnings as errors. Adds flag to treat warnings as errors, and addresses the numerous formatting issues that resulted in errors. In some cases, the footnote no longer made sense to retain and was as such removed. Change-Id: Ie80d9c4480507c52fd0f3eee41fd6478e4c5c758
This commit is contained in:
Julia Kreger
parent
f8816d0b3c
commit
f1f559c313
|
|
@ -39,7 +39,7 @@ Example use cases:
|
|||
remote sites from a central location. With the current setup of L2 dependency
|
||||
we need to provide VPN L2 tunnel between Ironic Conductor and remote target
|
||||
server.
|
||||
example: Edge cloud servers or Distributed VNF Flexi Zone Controllers:[5].
|
||||
example: Edge cloud servers or Distributed VNF Flexi Zone Controllers [5]_.
|
||||
|
||||
Proposed change
|
||||
===============
|
||||
|
|
@ -65,8 +65,8 @@ nodes which can be derived as follows:
|
|||
network.
|
||||
|
||||
Ironic virtmedia boot interfaces can use this derived information to construct
|
||||
os-net-config JSON structure:[2]. This would be added as "host_network_info" in
|
||||
parameters.txt when running create_vfat_image:[1].
|
||||
os-net-config JSON structure [2]_. This would be added as "host_network_info"
|
||||
in parameters.txt when running create_vfat_image [1]_.
|
||||
|
||||
Example:- Content for *host_network_info*
|
||||
|
||||
|
|
@ -132,8 +132,8 @@ dependency.
|
|||
Alternatives
|
||||
------------
|
||||
|
||||
glean:[3] can also be used instead of os-net-config:[2]
|
||||
Ignition:[4] can also be used instead of os-net-config:[2]
|
||||
glean [3]_ can also be used instead of os-net-config [2]_
|
||||
Ignition [4]_ can also be used instead of os-net-config [2]_
|
||||
|
||||
Data model impact
|
||||
-----------------
|
||||
|
|
|
|||
|
|
@ -52,9 +52,9 @@ New behavior of agent deploy driver methods:
|
|||
no_proxy='192.168.1.5,10.0.0.3'
|
||||
|
||||
If "proxies" key is present IPA adds a parameter to requests.get() method.
|
||||
Requests library supports "no_proxy" only as environment variable, not as a
|
||||
get() parameter. If "no_proxy" parameter is set agent should add it to Python's
|
||||
"os.environ" before get() call.
|
||||
Requests library [0]_ supports "no_proxy" only as environment variable, not as
|
||||
a get() parameter. If "no_proxy" parameter is set agent should add it to
|
||||
Python's "os.environ" before get() call.
|
||||
|
||||
Swift Temporary URL changes:
|
||||
|
||||
|
|
@ -204,4 +204,4 @@ Usage of agent's proxy configuration will be documented.
|
|||
References
|
||||
==========
|
||||
|
||||
.. [#] http://docs.python-requests.org/en/latest/user/advanced/#proxies
|
||||
.. [0] http://docs.python-requests.org/en/latest/user/advanced/#proxies
|
||||
|
|
|
|||
|
|
@ -23,8 +23,8 @@ UCSM managed servers.
|
|||
Proposed change
|
||||
===============
|
||||
|
||||
It proposes implementing the RAID interface as described by the parent spec [1]
|
||||
for UCS drivers.
|
||||
It proposes implementing the RAID interface as described by the parent spec
|
||||
[1]_ for UCS drivers.
|
||||
|
||||
List of changes required:
|
||||
|
||||
|
|
|
|||
|
|
@ -12,14 +12,14 @@ https://bugs.launchpad.net/ironic/+bug/1712032
|
|||
|
||||
The proposal is intended to create a new hardware interface for BIOS automated
|
||||
configuration and a method to make BIOS configuration available as part of
|
||||
manual cleaning [0].
|
||||
manual cleaning [0]_.
|
||||
|
||||
Problem description
|
||||
===================
|
||||
|
||||
* There are several use cases that need to configure BIOS options to enable
|
||||
certain functionality or gain performance optimization on OpenStack baremetal
|
||||
nodes. For example, in order to use SRIOV [1] or DPDK [2] technologies, the
|
||||
nodes. For example, in order to use SRIOV [1]_ or DPDK [2]_ technologies, the
|
||||
'Virtualization Technology' BIOS option shall be enabled; to achieve
|
||||
deterministic low packet latency in real time scenario, BIOS options related
|
||||
to Power Management, CPU sleep states etc shall be disabled; another good
|
||||
|
|
@ -77,8 +77,8 @@ Alternatives
|
|||
Data model impact
|
||||
-----------------
|
||||
|
||||
* Unlike the RAID configuration [3], the target BIOS settings will be passed as
|
||||
an argument to cleaning step and not stored in the database.
|
||||
* Unlike the RAID configuration [3]_, the target BIOS settings will be passed
|
||||
as an argument to cleaning step and not stored in the database.
|
||||
|
||||
* The current BIOS config will be cached and will be stored in a separate BIOS
|
||||
table. The following database table and fields will be added:
|
||||
|
|
|
|||
|
|
@ -31,7 +31,7 @@ Proposed change
|
|||
===============
|
||||
|
||||
The proposed implementation consists in having the iPXE driver to create
|
||||
a Swift tempurl for the deploy ramdisk and kernel that the
|
||||
a Swift tempurl [0]_ for the deploy ramdisk and kernel that the
|
||||
node will boot as part of the config generation.
|
||||
|
||||
This also proposes adding a boolean configuration option under
|
||||
|
|
@ -173,4 +173,4 @@ this spec.
|
|||
References
|
||||
==========
|
||||
|
||||
.. [#] http://docs.openstack.org/kilo/config-reference/content/object-storage-tempurl.html
|
||||
.. [0] http://docs.openstack.org/kilo/config-reference/content/object-storage-tempurl.html
|
||||
|
|
|
|||
|
|
@ -152,7 +152,7 @@ The process of mapping physical networks to ironic ports is out of scope for
|
|||
ironic. This could be done either through a manual procedure or through an
|
||||
automated process using information gathered during a hardware introspection
|
||||
process. For example, if using ironic inspector to perform introspection it
|
||||
would be possible to create an introspection plugin [6] that maps switch IDs
|
||||
would be possible to create an introspection plugin [6]_ that maps switch IDs
|
||||
discovered via LLDP to physical networks.
|
||||
|
||||
Portgroups
|
||||
|
|
|
|||
|
|
@ -157,7 +157,7 @@ Proposed change
|
|||
|
||||
.. note::
|
||||
The contents of the `properties` field depend on volume type. Reference
|
||||
information should be added in Bare Metal API document[1]:
|
||||
information should be added in Bare Metal API document:
|
||||
|
||||
For iSCSI example::
|
||||
|
||||
|
|
@ -223,7 +223,7 @@ Proposed change
|
|||
inspection, but that is not in the scope of this spec.
|
||||
|
||||
.. note::
|
||||
In the future, Ironic will provide driver capabilities information[3].
|
||||
In the future, Ironic will provide driver capabilities information.
|
||||
Nova can use that information to choose appropriate node.
|
||||
|
||||
* If a list of targets are specified, it's up to the driver handling the deploy
|
||||
|
|
@ -235,7 +235,7 @@ Proposed change
|
|||
|
||||
* Information which is stored in volume_connector and volume_target tables
|
||||
are used in drivers in order to boot the node from volume. Changes for
|
||||
reference driver, driver interfaces are described in the spec[4].
|
||||
reference driver, driver interfaces are described in the spec [4]_.
|
||||
|
||||
|
||||
Alternatives
|
||||
|
|
@ -264,7 +264,7 @@ Alternatives
|
|||
* Not implement storage of target and initiator information, which ultimately
|
||||
would not improve user experience and require manual post-deployment
|
||||
configuration for out-of-band control. For in-band use, Nova ironic driver
|
||||
can manage initiator information and it is proposed by jroll[2].
|
||||
can manage initiator information and it is proposed by jroll [2]_.
|
||||
|
||||
Data model impact
|
||||
-----------------
|
||||
|
|
@ -727,7 +727,7 @@ When spawning a new instance, Nova Ironic virt driver queries Ironic
|
|||
(through API) to find out the volume connector information. It passes the
|
||||
volume connector information to Cinder which returns the target information.
|
||||
This is then passed down to Ironic. Detailed information about Nova Ironic
|
||||
driver can be found in the spec [5].
|
||||
driver can be found in the spec [5]_.
|
||||
|
||||
Ramdisk impact
|
||||
--------------
|
||||
|
|
@ -740,7 +740,7 @@ Security impact
|
|||
None.
|
||||
|
||||
.. note::
|
||||
As for FC zoning, Cinder takes care of it[6].
|
||||
As for FC zoning, Cinder takes care of it [6]_.
|
||||
|
||||
|
||||
Other end user impact
|
||||
|
|
@ -867,11 +867,7 @@ explain the newly added fields and end points.
|
|||
References
|
||||
==========
|
||||
|
||||
.. [1] http://developer.openstack.org/api-ref/baremetal/index.html
|
||||
.. [2] https://review.openstack.org/#/c/184652/
|
||||
.. [3] http://specs.openstack.org/openstack/ironic-specs/specs/backlog/driver-capabilities.html
|
||||
.. [4] https://review.openstack.org/#/c/294995
|
||||
.. [5] https://review.openstack.org/#/c/211101/
|
||||
.. [6] http://docs.openstack.org/mitaka/config-reference/block-storage/fc-zoning.html
|
||||
.. [7] https://blueprints.launchpad.net/ironic/+spec/cinder-integration
|
||||
.. [8] https://wiki.openstack.org/wiki/Ironic/blueprints/cinder-integration
|
||||
|
|
|
|||
Loading…
Reference in New Issue