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
This adds the ability to specify a different ansible install path when
running zuul-manage-ansible. Venv location list is also reversed so that
we prefer the venvs at the user specified location if present.
Finally docs are updated to more clearly specify there are two options
for managing ansible installations and why you should prefer
zuul-manage-ansible.
Change-Id: If84a92bc542e24eedac09f3dc9fd2954db43734c
The docs missed the usage options of zuul-manage-ansible. This is
important as this documents how to add additional dependencies to
ansible during installation.
Change-Id: Iedb0d179a86130b72e314855a94feef98c454654
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
So that people can re-use the Dockerfiles to build zuul images
but with different flags set, plumb the env vars through here
as ARG entries.
Also, fix 2 doc references that were misspelled.
Change-Id: I320a496eadf4132fc0583dd48a87024a2ff61a07
ZooKeeper is mentioned under the Nodepool external dependency
section, but really needs to be in its own section to make
it more easily identifiable as an external system.
Change-Id: I8dea96eee7062769f0ce72c463c48fc8dfa329ad
Static offloading is fragile and more subject to change than
the simple reverse proxy, so emphasize the simple case in
documentation.
Change-Id: I19aaba595c4f1a392bad2be2969a9ed600c30d2f
This makes a number of changes to the installation/configuration
documentation in the admin manual.
Remove quick-start guide. The process of quick-starting is
covered by the installation and setup tutorial, which is now the
first of the installation sections. The reference material from
quick-start is now in the tutorial.
Rename the tutorial quick-start. It's nice to have something
named quick-start, and the tutorial fits the bill.
Rename the installation section "Installation Reference". This
now has more detailed information about installation and
deployment choices, but has very little procedural documentation.
Make zuul-from-scratch more internally consistent in style (use
code-block:: shell and heredocs wherever possible).
Change-Id: I7e4714ce5e775dc9ac0988c3470eef1f74fb36d6
Revert "Fix publish-openstack-javascript-content"
This reverts commit ca199eb9db.
This reverts commit 1082faae95.
This appears to remove the tarball publishing system that we rely on.
Change-Id: Id746fb826dfc01b157c5b772adc1d2991ddcd93a
The existing structure with the API and HTML interleaved makes it hard
to have apache do html offloading for whitelabeled deploys (like
openstack's) where the api and web are served from the same host.
Similarly, the tenant selector in the url for the html content being bare
and not prefixed by anything makes it harder to pull routing information
javascript-side.
Introduce an 'api' prefix to the REST API calls so that we can apply
rewrite rules differently for things starting with /api than things that
don't. Add the word 'tenant' before each tenant subpath.
Also add a '/t/' to the url for the html, so that we have anchors for
routing regexes but the urls don't get too long and unweildy.
Finally, also add /key as a prefix to the key route for similar reasons.
Change-Id: I0cbbf6f1958e91b5910738da9b4fb4c563d48dd4
The endpoint field in the info payload is intended to help the
javascript web code find out where the API endpoint is, and to allow
people who are deploying html/js as static assets to an external web
server drop a json file in that deployment to tell it where their
zuul-web server is.
The only scenario where the endpoint information as served by the /info
or /{tenant}/info endpoints of zuul-web is useful is
same-host/single-apache deployments that are hosted on a sub-url ... and
unfortunately, it's not possible for the aiohttp code to be aware of
such suburl deployments from http headers. request.url has the actual
location (such as http://localhost:8080/info) and X-Forwarded-Host will
only contain the host, not the path.
The actual important aspects of the payload are:
* A payload always be able to be found no matter the deployment
scenario.
* That a deployer can communicate to the javascript code the root of the
REST API in the scenarios where relative paths will resolve to the
incorrect thing.
With that in mind, change the Info.endpoint field returned by zuul-web
to default to None (or actually json null), or to a value provided by
the deployer in the zuul.conf file similar to websocket_url.
This way the web app can view 'null' as meaning "I'm deployed in such a
manner that relative paths are the correct thing to fetch from" and a value
as "the deployer has told me explicitly where to fetch from, I will join
my relative paths to the value first."
Because it is a value that is provided by the deployer if it is to
exist, rename it to "rest_api_url" to better match websocket_url and
stats_url.
Change-Id: I6b85a93db6c70c997bbff1329373fbfc2d1007c6
Refresh the user and admin guide for v3 changes, and reorganize into
a narrative structure which makes more sense for v3.
Change-Id: I4ac3b18d5ed33b0fea4e2ef0318b19bfc3447ccc
David Shrewsbury