Merge "Fix: various documentation and URL fixes"
This commit is contained in:
commit
1d0cdd288a
|
@ -241,4 +241,4 @@ References
|
|||
|
||||
.. _Kubernetes: https://kubernetes.io/
|
||||
.. _Kubernetes node labels: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/
|
||||
.. _Baremetal Nodes: https://airshipit.readthedocs.io/projects/drydock/en/latest/topology.html#host-profiles-and-baremetal-nodes
|
||||
.. _Baremetal Nodes: https://airship-drydock.readthedocs.io/en/latest/topology.html#host-profiles-and-baremetal-nodes
|
||||
|
|
|
@ -258,7 +258,7 @@ Query Parameters:
|
|||
|
||||
Responses
|
||||
~~~~~~~~~
|
||||
All responses will be form of the UCP Status response.
|
||||
All responses will be form of the Airship Status response.
|
||||
|
||||
- Success: Code: 200, reason: Success
|
||||
|
||||
|
@ -293,7 +293,7 @@ Query Parameters:
|
|||
|
||||
Responses
|
||||
~~~~~~~~~
|
||||
All responses will be form of the UCP Status response.
|
||||
All responses will be form of the Airship Status response.
|
||||
|
||||
- Success: Code: 200, reason: Success
|
||||
|
||||
|
@ -327,14 +327,14 @@ Query Parameters:
|
|||
|
||||
Responses
|
||||
~~~~~~~~~
|
||||
All responses will be form of the UCP Status response.
|
||||
All responses will be form of the Airship Status response.
|
||||
|
||||
- Success: Code: 200, reason: Success
|
||||
|
||||
The status of each etcd in the site will be returned in the details section.
|
||||
Valid values for status are: Healthy, Unhealthy
|
||||
|
||||
https://github.com/att-comdev/ucp-integration/blob/master/docs/source/api-conventions.rst#status-responses
|
||||
https://github.com/openstack/airship-in-a-bottle/blob/master/doc/source/api-conventions.rst#status-responses
|
||||
|
||||
.. code:: json
|
||||
|
||||
|
@ -395,7 +395,7 @@ label added, and then perform the kubelet teardown.
|
|||
|
||||
Responses
|
||||
~~~~~~~~~
|
||||
All responses will be form of the UCP Status response.
|
||||
All responses will be form of the Airship Status response.
|
||||
|
||||
- Success: Code: 200, reason: Success
|
||||
|
||||
|
@ -428,7 +428,7 @@ respond with a 409 Conflict response.
|
|||
|
||||
Responses
|
||||
~~~~~~~~~
|
||||
All responses will be form of the UCP Status response.
|
||||
All responses will be form of the Airship Status response.
|
||||
|
||||
- Success: Code: 200, reason: Success
|
||||
|
||||
|
@ -501,7 +501,7 @@ Enhancements
|
|||
|
||||
The completion tags should only be applied upon failure if the site action
|
||||
gets past document validation successfully (i.e. gets to the point where it
|
||||
can start making changes via the other UCP components)
|
||||
can start making changes via the other Airship components)
|
||||
|
||||
This could result in a single revision having both site-action-success and
|
||||
site-action-failure if a later re-invocation of a site action is successful.
|
||||
|
|
|
@ -50,7 +50,7 @@ update_site workflow (and perhaps other workflows in the future) invokes
|
|||
Drydock to verify the site, prepare the site, prepare the nodes, and deploy the
|
||||
nodes. Each of these steps is described in the `Drydock Orchestrator Readme`_
|
||||
|
||||
.. _Drydock Orchestrator Readme: https://git.openstack.org/cgit/openstack/airship-drydock/plain/drydock_provisioner/orchestrator/readme.md
|
||||
.. _Drydock Orchestrator Readme: https://git.openstack.org/cgit/openstack/airship-drydock/tree/python/drydock_provisioner/orchestrator/readme.md
|
||||
|
||||
The prepare nodes and deploy nodes steps each involve intensive and potentially
|
||||
time consuming operations on the target nodes, orchestrated by Drydock and
|
||||
|
@ -69,7 +69,7 @@ Some factors that advise this solution:
|
|||
3. Miswiring or configuration of network hardware.
|
||||
4. Incorrect site design causing a mismatch against the hardware.
|
||||
5. Criticality of particular nodes to the realization of the site design.
|
||||
6. Desired configurability within the framework of the UCP declarative site
|
||||
6. Desired configurability within the framework of the Airship declarative site
|
||||
design.
|
||||
7. Improved visibility into the current state of node deployment.
|
||||
8. A desire to begin the deployment of nodes before the finish of the
|
||||
|
|
Loading…
Reference in New Issue