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
Prominently in the Zuul User Guide, include a brief overview of
preferred methods for reporting suspected security vulnerabilities.
Also link to it from the README in such a way that the same
reference can be reused in other related Zuul repositories following
the same policy.
Change-Id: I2bd13bd13372f26c328cd7d6b5618ee8edffe490
Switch to use https://zuul-ci.org/docs/ for documentation links.
Change-Id: Ie52f025994e982ff2298696f79e8f0718946e7b3
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
We now have a git mirror at git.zuul-ci.org with only the Zuul
git repos. Update references to git.openstack.org to use that.
Change-Id: I3e7b3b2e19468521548cc5179bbb2bf6d037ddf0
Update the README to mention that some files are licensed under
the GPL. Include a copy of the GPL in the repo.
Also update the README to reflect the state of the project now that
we are approaching the v3 release.
Change-Id: I572dc565bf5cc1a89af476c7461236aa325a7bd6
There are two other projects named zuul. Let's make sure we disambiguate
so users aren't confused.
Change-Id: I6c459d062970e2abcbb890d626297595d979d324
To avoid confusion with nodepool-launcher, we've decided to rename
zuul-launcher to zuul-executor.
Change-Id: I7d03cf0f0093400f4ba2e4beb1c92694224a3e8c
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
Adds a link to a storyboard search for low-hanging-fruit.
Updates the roadmap to reflect some tasks having been completed,
and one re-ordered (we were able to run jobs on zuul earlier than
expected).
Change-Id: Ibd56f61a0b7b5a48c048c2277e7d050dd8ebf9c6
This includes forward-porting changes to launcher/server.py with the
exception of the pre/post playbooks changes which will be done in a
follow up commit as they have deviated.
Change-Id: I13aa229c1460b748745babe178c0a745e52f841c
Some of this is temporary and reflects how Zuul v3 development
work is proceeding at this moment. It will eventually be simplified
or removed.
The rest probably needs to eventually move into a more substantial
contributing section in the documentation.
Change-Id: I2b9109aa2c0bfbb865893bd59bdeb9ea4c03fff2
The ability to configure success and failure URL patterns (cf.
'success-pattern' and 'failure-pattern') obsoletes the need to
guess-by-fetching an appropriate link for the build status, which can be
extremely expensive. (Wikimedia's Zuul instance makes three HTTP requests per
invocation -- 'testReport', which 302s to 'testReport/', which 404s, and then
'consoleFull', which often runs to hundreds of kilobytes.)
Also corrects a small typo in README.rst.
Change-Id: Ib222f544c98253152a5e787ec0cdf28fa2d80cf6
Reviewed-on: https://review.openstack.org/28128
Reviewed-by: James E. Blair <corvus@inaugust.com>
Approved: Clark Boylan <clark.boylan@gmail.com>
Reviewed-by: Clark Boylan <clark.boylan@gmail.com>
Tested-by: Jenkins
Change-Id: Iceb9049640aa3e0ff5c030fa5b93225e1e8ff887
Signed-off-by: Paul Belanger <paul.belanger@polybeacon.com>
Reviewed-on: https://review.openstack.org/26381
Reviewed-by: James E. Blair <corvus@inaugust.com>
Approved: Monty Taylor <mordred@inaugust.com>
Reviewed-by: Monty Taylor <mordred@inaugust.com>
Tested-by: Jenkins
Tim Burke