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
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
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
So that this role may be used unconditionally in jobs which may
or may not actually build images, skip the tasks if the
docker_images variable is undefined.
Change-Id: I6ef0c80230de628f86f523878020c82ce81a1e60
This relies on the list merge behavior in https://review.openstack.org/638005
however, this will work with the current code in Zuul as long as only
one artifact is returned, so a Depends-On is not necessary.
Change-Id: Ie5d3a61c8cc1038f3775a3aa81e94b9b909f265a
* 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
Ian Wienand