Go to file

David Shrewsbury 26ad94ec52 Add support for python 3 for nodepool

Allow our nodepool installations to be installed under python 3.
Goal is to eventually remove py2 support from nodepool for zuulv3.

Change-Id: Icac77f88e411a3ac08fc54afb4e9746039f908e8
Depends-On: Ie2c223d74b32798e5f0cb0ca8b76d9fa6a4f3095

2017-07-19 11:30:48 -04:00

contrib

Pass Java arguments to Jenkins master

2017-03-28 10:41:38 +03:00

doc/source

Merge "added Single Use Slave plugin"

2017-06-05 15:27:06 +00:00

files

Reduce log archive to 30 days

2017-03-17 17:39:29 -07:00

manifests

Add support for python 3 for nodepool

2017-07-19 11:30:48 -04:00

spec

Fix beaker-rspec tests for centos7

2017-04-13 22:37:52 +02:00

templates

Set json.gz mimetype properly

2017-05-25 15:08:57 -07: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

bindep.txt

Move other-requirements.txt to bindep.txt

2016-08-12 19:30:33 +02:00

CONTRIBUTING.rst

Add a CONTRIBUTING.rst document

2016-01-07 17:34:58 -08:00

Gemfile

Use new infra_spec_helper for gem dependencies

2016-06-21 17:57:36 -07:00

LICENSE

Initial files for the puppet-openstackci repo

2015-03-24 12:05:27 -07:00

metadata.json

Use our custom pip provider for keyring package

2016-04-22 09:25:49 -07:00

Rakefile

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

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.