a15c433bc8
This is the first in a series of changes to alter the way modules are handled. This change removes the module section from yaml. Instead, all files in modules/ are imported, and a 'register' function is called if it exists. The register function can add (any number of) module classes to a module registry. The registry will also keep track of helper functions for use by other modules, and the register function can add those. This sets up the ability for a module other than the 'builders' module to register builders. Eventually, we should be able to move all OpenStack specific builders, publishers, etc outside of the base modules; instead we would just register an 'openstack_pep8' builder in a module of our own that the job filler would know to invoke. The API for modules is slightly changed, adding a root_xml method to handle the different project types, a handle_data method for modules that want to modify the yaml data structure before any XML is generated, and a data parameter is added to the generate_xml method. Ideally, we will migrate those modules that count on having a centrally stored data object to using the one passed into this method to allow maximum flexibility. I also envision some project-level yaml attributes to be moved closer to the handlers that use them. This change does inadvertently alter the XML produced. Here is the result of test.sh: http://paste.openstack.org/show/18585/ In all cases, those are inconsistencies in the YAML that are corrected by this change. Some jobs included an empty triggers vector (due to module trigger_none) while others did not, so there was no way to satisfy both behaviors. The added postbuilder section in the gerrit maven job is there because the job specified postbuilders, but did not include the postbuilder module. I believe the resulting XML is more desirable. Change-Id: Ib38222e6bfc9d5b55aa497669d7023c7aaf4b7bc
These are a set of puppet manifests and modules that are currently being used to manage some of the efforts of the OpenStack CI project. They are quite bare and crappy at the moment, but should grow soon.
Additionally, there is a script, make_puppet_lp.py which is used to generate a few lists of users from launchpad teams, to make management and population of user accounts on different types of servers easier.
There are currently two different entry points, the slave.pp and the server.pp manifest.
slave.pp is intended to be for jenkins slaves and adds all members of ~openstack-ci-admins
server.pp is intended as the base for other servers and adds members of ~openstack-admins
Puppet needs to be installed via gems, because we use the pip package provider for one of the packages and that is only in 2.7.
For instance:
/var/lib/gems/1.8/bin/puppet apply --modulepath=pwd/modules manifests/slave.pp
or
/var/lib/gems/1.8/bin/puppet apply --modulepath=pwd/modules manifests/server.pp