93d1d3be17
The nodepool "python-path" config variable makes it's way through from the node arguments and ends up as the "ansible_python_interpreter" variable for the inventory when running the job. Notably, Python 3 only distributions require this to be set to /usr/bin/python3 to avoid what can often be confusing red-herring errors (e.g. things like dnf packages incorrectly appearing to be missing on Fedora, for example [1]). Upstream is aware of this often confusing behaviour and has made an "ansible_python_interpreter" value of "auto" to, essentially, "do the right thing" [2] and choose the right python for the target environment. This is available in Ansible >=2.8 and will become default in 2.12. This allows, and defaults to, an interpreter value of "auto" when running with Ansible >=2.8. On the supported prior Ansible releases, "auto" will be translated into "/usr/bin/python2" to maintain backwards compatability. Of course a node explicity setting "python-path" already will override this. Nodepool is updated to set this by default with I02a1a618c8806b150049e91b644ec3c0cb826ba4. I think this is much more user friendly as it puts the work of figuring out what platform has what interpreter into Ansible. It alleviates the need for admins to know anything at all about "python-path" for node configurations unless they are actually doing something out of the ordinary like using a virtualenv. At the moment, if you put a modern Python-3 only distro into nodepool, Zuul always does the wrong thing by selecting /usr/bin/python2; you are left to debug the failures and need to know to go and manually update the python-path to Python 3. Documentation is updated. Detailed discussion is moved into the executor section; the README is simplified a bit to avoid confusion. A release note is added. A test-case is added. Note that it is also self-testing in that jobs using Ansible 2.8 use the updated value (c.f. I7cdcfc760975871f7fa9949da1015d7cec92ee67) [1] https://bugzilla.redhat.com/show_bug.cgi?id=1696404 [2] https://docs.ansible.com/ansible/2.8/reference_appendices/interpreter_discovery.html Change-Id: I2b3bc6d4f873b7d653cfaccd1598464583c561e7
2.1 KiB
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.