RETIRED, Puppet module to deploy an OpenStack ci system
Go to file
David Moreau Simard 6b351d7fa1
Synchronize vhost configuration between logs.o.o and logs-dev.o.o
It seems the vhost configurations have slightly diverged over time.
Let's synchronize them so we're able to test things accurately.

Change-Id: Ic921fcb3a310fbb9f728d73390d7740455ca4414
2018-04-04 11:46:16 -04:00
contrib Add support for installing ARA wsgi middleware for sqlite databases 2018-03-05 15:08:40 -05:00
doc/source Merge "added Single Use Slave plugin" 2017-06-05 15:27:06 +00:00
files Allow viewing of .log.gz files 2018-02-12 10:05:15 +11:00
manifests Setup WSGIDaemonProcess, ProcessGroup + ApplicationGroup for logs-dev 2018-04-03 23:35:47 -04:00
spec/acceptance Depend on helper gem for spec_helper_acceptance 2017-07-09 19:27:18 +02:00
templates Synchronize vhost configuration between logs.o.o and logs-dev.o.o 2018-04-04 11:46:16 -04:00
.gitignore Initial sphynx doc setup for publishing 2016-01-04 14:51:15 -08:00
.gitreview Added .gitreview 2015-03-18 17:00:55 +00:00
CONTRIBUTING.rst Add a CONTRIBUTING.rst document 2016-01-07 17:34:58 -08:00
Gemfile Check for presence of Zuul with Zuul v3 2017-11-20 09:23:50 -08:00
LICENSE Initial files for the puppet-openstackci repo 2015-03-24 12:05:27 -07:00
README.md Add developer guidelines 2015-04-29 01:46:24 -07:00
Rakefile Initial files for the puppet-openstackci repo 2015-03-24 12:05:27 -07:00
bindep.txt Move other-requirements.txt to bindep.txt 2016-08-12 19:30:33 +02:00
metadata.json Use our custom pip provider for keyring package 2016-04-22 09:25:49 -07:00
setup.cfg Initial sphynx doc setup for publishing 2016-01-04 14:51:15 -08:00
setup.py Initial sphynx doc setup for publishing 2016-01-04 14:51:15 -08:00
test-requirements.txt Initial sphynx doc setup for publishing 2016-01-04 14:51:15 -08:00
tox.ini Initial sphynx doc setup for publishing 2016-01-04 14:51:15 -08:00

README.md

OpenStack Continuous Integration Module

Overview

Configures an OpenStack Continuous Integration System

Developing

If you are adding features to this module, first ask yourself: "Does this logic belong in the module for the service?"

An example of this is the gearman-logging.conf file needed by the zuul service. This file should be managed by the zuul module, not managed here. What should go in this module is high level directives and integrations such as a list of jenkins plugins to install or a class that instantiates multiple services.