Reorganizing docs as recommended in:
https://www.divio.com/blog/documentation/
This is simply a reorganization of the existing documents and changes
no content EXCEPT to correct the location of sphinx doc references.
Expect followup changes to change document names (to reflect the new
structure) and to move content from existing guides (e.g., to move the
pipeline/project/job structure definitions out of the "Project Configuration"
reference guide into their own reference documents for easier locatability).
All documents are now located in either the "overview", "tutorials",
"discussions", or "references" subdirectories to reflect the new structure
presented to the user. Code examples and images are moved to "examples" and
"images" root-level directories.
Developer specific documents are located in the "references/developer"
directory.
Change-Id: I538ffd7409941c53bf42fe64b7acbc146023c1e3
Add the correct libre2 package name for Debian buster, and also
update the quickstart playbook and documentation to deal with
the change in default rsa key encoding format from newer
versions of ssh-keygen.
Change-Id: I6ada88cd896d844c1171f7bcaf4691dea023d51f
When the quickstart job fails, make sure that we get stderr from
the docker logs. Also, add timestamps to the waiting to start
script so that we can compare when it gave up to when systems
came online.
Change-Id: I632c794de7fb792fbe7d0b8e095701a5d7fd1af7
As a first step towards supporting multiple ansible versions we need
tooling to manage ansible installations. This moves the installation
of ansible from the requirements.txt into zuul. This is called as a
setup hook to install the ansible versions into
<prefix>/lib/zuul/ansible. Further this tooling abstracts knowledge
that the executor must know in order to actually run the correct
version of ansible.
The actual usage of multiple ansible versions will be done in
follow-ups.
For better maintainability the ansible plugins live in
zuul/ansible/base where plugins can be kept in different versions if
necessary. For each supported ansible version there is a specific
folder that symlinks the according plugins.
Change-Id: I5ce1385245c76818777aa34230786a9dbaf723e5
Depends-On: https://review.openstack.org/623927
Gerrit 2.16 was released and is more strict about the content-type
header on ssh key uploads. Specify it is text/plain (which is what
the documentation indicates it should be).
Change-Id: Ic1b60737df5aeea5b1b44ea3dea63e7020366f95
To improve the experience for new users, have the mergers automatically
add new ssh hosts to their known hosts files. They will still validate
existing entries, so a paranoid sysadmin can still pre-populate the file
to avoid trojan attacks on the initial connection. New users in the
typical case of a secure internal network will not need to manually add
host keys to start Zuul.
This matches the behavior of the scheduler with its stream-events
connection to Gerrit.
Change-Id: Ib416bbb2ffcfedd5d114709af3931e154a1a92ac
It takes a long time to install ansible, but we have it installed
already in the zuul image (for the executor). Just use that instead.
Change-Id: I2dc2d6f5e5e83bb0654c45b27b8d37dc161f7841
* Tell folks to run 'sudo docker-compose up' in case their user
is not in the docker group.
* Turn off fact gathering in playbooks because we've seen some
leakage of device information from the host into the container
which causes ansible to query device info that doesn't exist.
We don't use facts anyway so this is faster too.
* Use register instead of rescue to figure out if users/projects
need to be created. It makes the ansible output tidier since
there won't be any (expected) failure tasks.
* Use the alpine image instead of centos for the gerritconfig
container. We're more likely to be able to re-use this layer
between this and the Zuul images than we would with centos
(because the gerrit container over-specifies the centos version).
* Capitalize the task names in playbooks. It looks better.
Change-Id: I428a2aea4e7544e04771d89e8d5627431cfaf1de
Use docker-compose to get a zuul+nodepool+gerrit up and configured
so that we can write walkthrough documentation which starts with
a running system.
Change-Id: I5819aee1fb9c3af72eb31818da476df074424225
Co-Authored-By: Tobias Henkel <tobias.henkel@bmw.de>
David Shrewsbury