diff --git a/doc/source/open-infrastructure.rst b/doc/source/open-infrastructure.rst index e86750b5f1..85cd6e8ac5 100644 --- a/doc/source/open-infrastructure.rst +++ b/doc/source/open-infrastructure.rst @@ -92,7 +92,7 @@ the (ephemeral) production-test nodes. This is generally the first stop for finding deployment issues. Another artifact is the ``testinfra results``. `Testinfra -`__ allows us to define +`__ allows us to define unit-test-like behaviour to test functionality such as service and API status, correct deployment of users and files and other interesting details. Failures here would indicate the the deployment steps @@ -169,7 +169,7 @@ These jobs are named ``infra-prod-`` and run the same playbooks and roles as in the CI system, except against the production services. Zuul will deploy the merged changes to the bastion host, and then trigger the bastion host to run a *nested* Ansible deployment -against the production host.. +against the production host. Since the production run logs may leak sensitive information, they are not published openly. You can add a GPG public key to @@ -188,7 +188,7 @@ on container build/upload/promote jobs; this indicates we have jobs that build a bespoke container for this environment. The base ``Dockerfile`` for these containers is found under -:git_file:``docker/``. Most are straight forward, but some of the more +:git_file:`docker/`. Most are straight forward, but some of the more complicated services have multiple steps and layers. Any changes to the ``Dockerfile`` will be tested as usual, and when approved the containers will be rebuilt, published and pulled onto the production