fbb17e1f35
Rather than decrypting secrets on the scheduler and sending them to the executors unencrypted, now that the private keys are in ZK and the executors have access to them, we can defer decryption to the executors. This means that when we move the build requests from gearman to ZK, we avoid storing decrypted secrets in ZK. We accomplish this by serializing the entire secret (parts or all of which may be encrypted or plaintext) to YAML in the scheduler and deserializing the YAML into a Secret object on the executor. We do this because we already have support for indicating an encrypted value via custom YAML tags. This means that the build request (which is currently transmitted via gearman and soon to be via ZK) serializes the rest of the job to JSON. This means we're storing a serialized-to-YAML secret as a scalar value in a serialized-to-JSON data structure. There's nothing technically wrong with this, and it is the minimal version of this change, however it's slightly unusual and may result in a little extra work. We may want to consider serializing the entire job request as YAML instead. Change-Id: I6d94c1d8da8b68e5fb60c27e73039155a02fb485 |
||
|---|---|---|
| doc | ||
| etc | ||
| playbooks | ||
| releasenotes/notes | ||
| tests | ||
| tools | ||
| web | ||
| zuul | ||
| .coveragerc | ||
| .dockerignore | ||
| .gitignore | ||
| .gitreview | ||
| .mailmap | ||
| .stestr.conf | ||
| .zuul.yaml | ||
| COPYING | ||
| Dockerfile | ||
| LICENSE | ||
| MANIFEST.in | ||
| README.rst | ||
| TESTING.rst | ||
| bindep.txt | ||
| reno.yaml | ||
| requirements.txt | ||
| setup.cfg | ||
| setup.py | ||
| test-requirements.txt | ||
| tox.ini | ||
README.rst
Zuul
Zuul is a project gating system.
The latest documentation for Zuul v3 is published at: https://zuul-ci.org/docs/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
If you are looking for the Javascript testing tool named Zuul, it can be found here: https://github.com/defunctzombie/zuul
Getting Help
There are two Zuul-related mailing lists:
- zuul-announce
-
A low-traffic announcement-only list to which every Zuul operator or power-user should subscribe.
- zuul-discuss
-
General discussion about Zuul, including questions about how to use it, and future development.
You will also find Zuul developers in the #zuul channel on Freenode IRC.
Contributing
To browse the latest code, see: https://opendev.org/zuul/zuul To clone the latest code, use git clone https://opendev.org/zuul/zuul
Bugs are handled at: https://storyboard.openstack.org/#!/project/zuul/zuul
Suspected security vulnerabilities are most appreciated if first reported privately following any of the supported mechanisms described at https://zuul-ci.org/docs/zuul/user/vulnerabilities.html
Code reviews are handled by gerrit at https://review.opendev.org
After creating a Gerrit account, use git review to submit patches. Example:
# Do your commits
$ git review
# Enter your username if promptedJoin #zuul on Freenode to discuss development or usage.
License
Zuul is free software. Most of Zuul is licensed under the Apache License, version 2.0. Some parts of Zuul are licensed under the General Public License, version 3.0. Please see the license headers at the tops of individual source files.
Python Version Support
Zuul requires Python 3. It does not support Python 2.
Since Zuul uses Ansible to drive CI jobs, Zuul can run tests anywhere Ansible can, including Python 2 environments.