Fix: various documentation and URL fixes

1) UCP -> Airship
2) readthedocs.org -> readthedocs.io (there is redirect)
3) http -> https
4) attcomdev -> airshipit (repo on quay.io)
5) att-comdev -> openstack/airship-* (repo on github/openstack git)
6) many URLs have been verified and adjusted to be current
7) no need for 'en/latest/' path in URL of the RTD
8) added more info to some setup.cfg and setup.py files
9) ucp-integration docs are now in airship-in-a-bottle
10) various other minor fixes

Change-Id: I4231ce9df05fb491fae4daca4129fd4afed6c7d2
This commit is contained in:
Roman Gorshunov 2018-09-24 12:53:27 +02:00
parent d1fca12693
commit bde6ee07df
3 changed files with 10 additions and 10 deletions

View File

@ -241,4 +241,4 @@ References
.. _Kubernetes: https://kubernetes.io/ .. _Kubernetes: https://kubernetes.io/
.. _Kubernetes node labels: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/ .. _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

View File

@ -258,7 +258,7 @@ Query Parameters:
Responses 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 - Success: Code: 200, reason: Success
@ -293,7 +293,7 @@ Query Parameters:
Responses 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 - Success: Code: 200, reason: Success
@ -327,14 +327,14 @@ Query Parameters:
Responses 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 - Success: Code: 200, reason: Success
The status of each etcd in the site will be returned in the details section. The status of each etcd in the site will be returned in the details section.
Valid values for status are: Healthy, Unhealthy 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 .. code:: json
@ -395,7 +395,7 @@ label added, and then perform the kubelet teardown.
Responses 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 - Success: Code: 200, reason: Success
@ -428,7 +428,7 @@ respond with a 409 Conflict response.
Responses 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 - Success: Code: 200, reason: Success
@ -501,7 +501,7 @@ Enhancements
The completion tags should only be applied upon failure if the site action 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 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 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. site-action-failure if a later re-invocation of a site action is successful.

View File

@ -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 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`_ 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 The prepare nodes and deploy nodes steps each involve intensive and potentially
time consuming operations on the target nodes, orchestrated by Drydock and 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. 3. Miswiring or configuration of network hardware.
4. Incorrect site design causing a mismatch against the hardware. 4. Incorrect site design causing a mismatch against the hardware.
5. Criticality of particular nodes to the realization of the site design. 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. design.
7. Improved visibility into the current state of node deployment. 7. Improved visibility into the current state of node deployment.
8. A desire to begin the deployment of nodes before the finish of the 8. A desire to begin the deployment of nodes before the finish of the