#136 depcheck is using outside-of-Fedora-infra repos which causes timeouts and crashes
Closed: Fixed None Opened 8 years ago by kparal.

It seems our dev machine with disposable minions is not correctly configured, because depcheck often fails with mirroring issues, like this:

[depcheck] 14:34:48 INFO    Getting metadata...
[depcheck] 14:38:33 WARNING Mirror Error:  None Curl error (28): Timeout was reached for http://mirror.as24220.net/pub/fedora/linux/updates/testing/23/i386/repodata/repomd.xml [Connection timed out after 120877 milliseconds]
[libtaskotron] 14:38:33 CRITICAL Traceback (most recent call last):
Exception: Librepo Error 19: Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried 

http://taskotron-dev.fedoraproject.org/taskmaster/builders/x86_64/builds/96777/steps/runtask/logs/stdio

Notice http://mirror.as24220.net. We should not download metadata nor packages from the outside, we should use main Fedora infra location. It seems that we have not configured yumrepoinfo.conf on the dev machine to point baseurl to Fedora master repo, or that this configuration file is not properly copied to disposable minions.


This ticket had assigned some Differential requests:
D662

As an additional explanation, this is what happens if we use download.fedoraproject.org (the default value of baseurl) -- it gets redirected to a random mirror. But even worse, it gets redirected to a random mirror for every request, so we might receive non-matching metadata and packages. We should not use this as a default value (but then there's this hard question what to use as a default value), but that should be handled in a different ticket.

Yep, haven't got a chance to fix that but my guess is that we're missing libtaskotron-config in a disposable client, hence no yumrepoinfo.conf.

Yep, haven't got a chance to fix that but my guess is that we're missing libtaskotron-config in a disposable client, hence no yumrepoinfo.conf.

I take that back. We don't copy the config onto vm. I'll sent a fix shortly.

Unfortunately, there's another wrinkle to this: resolving the host names correctly. Our ansible-ized hosts have a custom /etc/hosts so that the repo hosts would resolve correctly to the internal hosts and that hosts file isn't on the disposable clients.

The two options I can think of are
# use IP addresses in the repo config instead of host names
# inject an /etc/hosts into the disposable clients @ boot with cloud-init like we do with ssh keys and will likely do with rsyslog config

I changed the config for cloud-init so that download.fp.o resolves to an internal mirror but now it's running out of space while doing depcheck which is a different problem :)

Either way, we should probably be copying some config to the disposable clients

# inject an /etc/hosts into the disposable clients @ boot with cloud-init like we do with ssh keys and will likely do with rsyslog config

This ticket is left open to resolve this as well.

inject an /etc/hosts into the disposable clients @ boot with cloud-init like we do with ssh keys and will likely do with rsyslog config

I think we can close this. Injecting /etc/hosts at boot time (via testcloud/cloud-init) is fine with me as it's specific to our deployment and doesn't need to be solved in libtaskotron. Please reopen if you think it should be done differently.

Metadata Update from @kparal:
- Issue tagged with: infrastructure

6 years ago

Login to comment on this ticket.

Metadata