Merge "Fix typos in doc/source/open-infrastructure.rst"
This commit is contained in:
commit
ac1ec70c5d
@ -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
|
||||
<https://testfinra.readthedoocs.io>`__ allows us to define
|
||||
<https://testinfra.readthedocs.io/>`__ 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-<service>`` 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
|
||||
|
Loading…
Reference in New Issue
Block a user