James E. Blair
We need routable addresses for streaming, so make sure we use the fqdn. Change-Id: I43cca352eb123bb484e3d51aa242ba4258c1d51e
|3 years ago|
|doc||3 years ago|
|etc||3 years ago|
|playbooks||4 years ago|
|tests||3 years ago|
|tools||3 years ago|
|zuul||3 years ago|
|.gitignore||4 years ago|
|.gitreview||9 years ago|
|.mailmap||9 years ago|
|.testr.conf||4 years ago|
|.zuul.yaml||3 years ago|
|LICENSE||9 years ago|
|MANIFEST.in||8 years ago|
|NEWS.rst||6 years ago|
|README.rst||3 years ago|
|TESTING.rst||4 years ago|
|bindep.txt||4 years ago|
|requirements.txt||3 years ago|
|setup.cfg||4 years ago|
|setup.py||8 years ago|
|test-requirements.txt||3 years ago|
|tox.ini||3 years ago|
Zuul is a project gating system developed for the OpenStack Project.
We are currently engaged in a significant development effort in preparation for the third major version of Zuul. We call this effort Zuul v3 and it is described in more detail below.
The latest documentation for Zuul v3 is published at: https://docs.openstack.org/infra/zuul/
If you are looking for the Edge routing service named Zuul that is related to Netflix, it can be found here: https://github.com/Netflix/zuul
We are currently engaged in a significant development effort in preparation for the third major version of Zuul. We call this effort Zuul v3.
To browse the latest code, see: https://git.openstack.org/cgit/openstack-infra/zuul/tree/ To clone the latest code, use git clone git://git.openstack.org/openstack-infra/zuul
Bugs are handled at: https://storyboard.openstack.org/#!/project/679
Code reviews are, as you might expect, handled by gerrit at https://review.openstack.org
Use git review to submit patches (after creating a Gerrit account that links to your launchpad account). Example:
# Do your commits $ git review # Enter your username if prompted
The Zuul v3 effort involves significant changes to Zuul, and its companion program, Nodepool. The intent is for Zuul to become more generally useful outside of the OpenStack community. This is the best way to get started with this effort:
Read the Zuul v3 spec: http://specs.openstack.org/openstack-infra/infra-specs/specs/zuulv3.html
We use specification documents like this to describe large efforts where we want to make sure that all the participants are in agreement about what will happen and generally how before starting development. These specs should contain enough information for people to evaluate the proposal generally, and sometimes include specific details that need to be agreed upon in advance. They are living documents which can change as work gets underway. However, every change or detail does not need to be reflected in the spec --most work is simply done with patches (and revised if necessary in code review).
Review any proposed updates to these specs: https://review.openstack.org/#/q/status:open+project:openstack-infra/infra-specs+topic:zuulv3
Some of the information in the specs may be effectively superceded by changes here, which are still undergoing review.
Read developer documentation on the internal data model and testing: http://docs.openstack.org/infra/zuul/developer.html
The general philosophy for Zuul tests is to perform functional testing of either the individual component or the entire end-to-end system with external systems (such as Gerrit) replaced with fakes. Before adding additional unit tests with a narrower focus, consider whether they add value to this system or are merely duplicative of functional tests.
Review open changes: https://review.openstack.org/#/q/status:open
We find that the most valuable code reviews are ones that spot problems with the proposed change, or raise questions about how that might affect other systems or subsequent work. It is also a great way to stay involved as a team in work performed by others (for instance, by observing and asking questions about development while it is in progress). We try not to sweat the small things and don't worry too much about style suggestions or other nitpicky things (unless they are relevant -- for instance, a -1 vote on a change that introduces a yaml change out of character with existing conventions is useful because it makes the system more user-friendly; a -1 vote on a change which uses a sub-optimal line breaking strategy is probably not the best use of anyone's time).
Check storyboard for status of current work items: https://storyboard.openstack.org/#!/board/41
Work items tagged with
low-hanging-fruit are tasks that have been identified as not requiring an expansive knowledge of the system. They may still require either some knowledge or investigation into a specific area, but should be suitable for a developer who is becoming acquainted with the system. Those items can be found at: https://storyboard.openstack.org/#!/story/list?tags=low-hanging-fruit&tags=zuulv3
Once you are up to speed on those items, it will be helpful to know the following:
Because of the importance of external systems, as well as the number of internal Zuul components, actually running Zuul in a development mode quickly becomes unweildy (imagine uploading changes to Gerrit repeatedly while altering Zuul source code). Instead, the best way to develop with Zuul is in fact to write a functional test. Construct a test to fully simulate the series of events you want to see, then run it in the foreground. For example:
.tox/py27/bin/python -m testtools.run tests.unit.test_scheduler.TestScheduler.test_jobs_executed
See TESTING.rst for more information.
Zuul v3 requires Python 3. It does not support Python 2.
As Ansible is used for the execution of jobs, it's important to note that while Ansible does support Python 3, not all of Ansible's modules do. Zuul currently sets
ansible_python_interpreter to python2 so that remote content will be executed with Python2.