We spawn socat processes in the background in buildset registry
related roles. Ansible 5 is much better at killing all processes
in its session when the task is complete. Work around that by
starting socat within a new session with setsid.
Change-Id: Iaab17f5d4068be6b08e3d89d2abe80199f0cd654
Zuul switched to a new base image, and it seems the new socat puts out
a warning (something like
... socat[489590] W ioctl(5, IOCTL_VM_SOCKETS_GET_LOCAL_CID, ...): Inappropriate ioctl for device
for reference).
Grep the output so we only get the line about what port it is
listening on.
Change-Id: I74fb86a9158b45e6601ee1fbc199ba80cd4991fe
Because buildset registries may be used by jobs that finish before other
jobs are finished using the buildset registry we must be careful not to
expose the registry credentials in the jobs that finish sooner.
Otherwise logs for the earlier job runs could potentially be used to
poison the registry for later jobs.
This is likely currently incomplete. Other Zuulians should look over it
carefully to ensure we're covering all the bases here.
The cases I've identified so far are:
* Setting facts that include passwords
* Reading and writing to files that include passwords (as content may be
logged)
* Calling modules with passwords passed as arguments (the module
invocation is logged)
I've also set no_log on zuul_return that passes up credentials because
while the logging for zuul_return is minimal today, I don't want to
count on it remaining that way.
We also use the yet to be merged secret_data attribute on zuul_return to
ensure that zuul_return itself does not expose anything unwanted.
Finally it would be great if others could check over the use of
buildset_registry variables to make sure there aren't any that got
missed. One thing I'm not sure of is whether or not when conditionals
get logged and if we need to be careful about their use too.
Temporarily remove some buildset-regitry jobs which are in a catch-22.
Change-Id: I2dea683e27f00b99a7766bf830981bf91b925265
skopeo needs to be told to copy all instances of a given image,
otherwise it just grabs one of them.
https://github.com/containers/skopeo/pull/741
Change-Id: If78ad50602e745ef7747d983b987cf964ff6e67f
We have to be careful about avoiding outer loop loop_var conflicts in
ansible. Because the zuul-jobs roles are meant to be reconsumed
elsewhere we should not use 'item' loopvars and instead set them to
something a bit more unique.
We use a zj_ prefix to try and be unique to this repo and document this
convention.
Change-Id: I20b9327a914890e9eafcb2b36dc8c23fb472bc8f
We think that sometimes the network derps so the whole copy goes
bad. Add retries in to the mix since a copy command is idempotent.
Change-Id: I2d2891f2ebe3ca6a99874d9cf028addea888c3b7
We're using 127.0.0.1 everywhere rather than localhost; the cert
directory and auth information need to match.
Change-Id: Id72332625c234519ce4c819e88c184035eac8203
Skopeo has problems with ipv6 address literals just like docker as they
use the same underlying checks for url validity. However, we think we
can fix that by using a port forward from the executor to the buildset
registry so that skopeo can connect via ipv4
Go back to aliases the registries on test nodes via /etc/hosts.
Change-Id: I5f9316ffe84de06cb2fb2b65a7e1c31d9f8b0e35
Co-Authored-By: James E. Blair <jeblair@redhat.com>
This reverts commit 05f20a5396.
Apparently skopeo is properly cloud native too and doesn't support ipv6
either. I think it is pulling the same docker
distribution/reference/regexp.go lib in and using docker's regex.
The error we get from skopeo:
time="2019-04-10T15:15:48Z" level=fatal msg="Invalid source name docker://[2607:ff68:100:54:f816:3eff:fef2:fc69]:5000/zuul/nodepool:latest: invalid reference format"
Change-Id: I6f916574c9f46e8fdd2464465e2b36ecf8719b16
We only need to alias registries on the build nodes when running docker.
We cannot alias them in /etc/hosts in roles that are expected to run on
localhost beacuse /etc/hosts is bindmounted read only on localhost. This
assumes that skopeo handles ipv6 properly (which has not been tested).
If skopeo does not handle ipv6 properly then we'll need additional
fixing.
Change-Id: I40e5b1bac5aeaf2d42aa05a72b9ced72b7d222c0
This reverts commit a307259776.
We need to additionally handle this on localhost (the zuul executor)
where we cannot edit /etc/hosts. At least I don't think we can. We also
need to handle the case where buildset_regsitry is not yet defined.
Change-Id: I4928f7fcf58e88cf360de253f01b16546220aace
Docker doesn't appear to understand properly escaped ipv6 addrs in its
"urls". Address this by adding /etc/hosts entries for any
buildset_registry that is specified by an ip address (v4 or v6). This
allows us to use a named alias instead of the ipv6 address.
An example failure for posterity:
"[2607:ff68:100:54:f816:3eff:fe7c:e98a]:5000/zuul/nodepool:latest" is not a valid repository/tag: invalid reference format
Change-Id: Id865dc7d3382174b61f9eaa76e29b637a85f5142
A recent change to make this safer is causing the error:
The conditional check 'metadata in item and item.metadata.type | default('')
== 'container_image'' failed. The error was: error while evaluating conditional
(metadata in item and item.metadata.type | default('') == 'container_image'):
'metadata' is undefined
Change-Id: Ib709996dc950466a3673c422cd288ba874187f5c
When pulling from intermediate registries we check zuul for artifacts of
a certain type. Unfortunately we do so blindly without checking that the
metadata field exists for the artifact. These leads to errors like:
"msg": "The conditional check 'item.metadata.type | default('') == 'container_image'' failed.
The error was: error while evaluating conditional (item.metadata.type | default('') == 'container_image'): 'dict object' has no attribute 'metadata'
http://logs.openstack.org/12/643712/1/gate/opendev-buildset-registry/1016e6e/job-output.txt.gz#_2019-03-18_19_28_39_060210
Address this by checking the metadata field prior to accessing it.
Change-Id: I02bbeddccdda836fc313eccce09e4cb0beb6262a
This was copy/pasta from the use_buildset_registry role; the
intermediate registry has no proxy_port, and the push/pull operations
don't need to use the proxy buildset registry, so remove both
entries from the docker config.
Change-Id: I7c2d57d027e457f4f093497938574624cd5a444c
Use the docker user config file rather than the skopeo command line
when performing skopeo push/pull operations. This should allow
us to log the command.
Change-Id: If6b1f3ab34461d77e619b188f48c5d209df7afce
The approach of having the proxy serve the local data as well as
the remote wasn't working -- it seems that the proxy would always
check upstream and prefer that data even if it had been pushed
locally.
To correct this, separate the data stores of the two registries,
and add both of them to the registry_mirror setting for the
docker daemon. Now we will pull from our buildset registry first,
and fall back on the proxy to talk to upstream if an image is not
found locally.
The proxy is still required in order to mask out the username and
password which dockerd will otherwise use when talking to upstream.
Change-Id: Iab11954a4b5431d3b1a4d4753f519b6b71f64094
When copying images from the intermediate registry to the buildset
registry, use the new push endpoint of the dual-registry system.
Also, use the push endpoint after a docker build to push the
new image to the buildset registry.
Change-Id: I3a11036bb9fb7cb3457a3d744fa83647c1b1b085
The intermediate registry pull role is designed to be used in
the same playbook as the run-buildset-registry role, which sets
the buildset_registry fact. However, that fact is set on the
host where the registry runs, not localhost. Theoretically we
should be able to delegate setting that fact to all hosts in
the inventory, plus localhost, however, that doesn't seem to
work in local testing.
Work around this by, once again, loading the buildset_registry
fact from the zuul_return file.
Change-Id: Ia16b3af8782c875e64ad5eeeeb5f107482a3e30a
* In the build-image role, push to the buildset registry if it is defined.
* In the intermediate registry push and pull roles, ensure that the
buildset registry TLS cert is in place. This is a self-signed cert,
and so needs to be written for each run. This happens inside
bubblewrap where we have permission to write to /etc, which is an
ephemeral volume.
Change-Id: I47781d8a7adb93817dfe9266e2f4ad5fd829385c
There is no policy file available, and we aren't concerned with
verifying image signatures at this point. Add this option to
tell skopeo to proceed regardless.
Change-Id: I15a4978ec0fb338bc05c974b0ec6a21f680c853e
The attribute zuul.artifacts is only present if there are artifacts.
Use the empty list as default.
The default for image.tags should be 'latest' to match the rest
of the docker roles.
Change-Id: Iff6863043e3a0311cb1c8c2ef4cd3d37ff79cce5