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
The proxy functionality is no longer needed so it is removed.
Change-Id: I29ff75d331b433ea4ad3b66ed723eee14a90b404
Depends-On: https://review.opendev.org/689829
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
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
To accomodate running in a production-simulation environment,
make it safe to run this role on a host before docker is installed.
This also adds support for the new dual-registry configuration
that run-buildset-registry uses.
This removes the region-local proxy from the registry-mirrors
configuration. Because the buildset registry acts as a pull-through
proxy, the region-local proxy won't be used even if we did include it.
Instead, we should update the run-buildset-registry role to proxy
to the region-local proxy if present.
Change-Id: I21011a3708f17ee61afd0034d90d75e8dc885575
Clark Boylan