Red Hat Bugzilla – Bug 1005021
beaker-sync-tasks fails if task XML refers to an internal hostname that is not publicly accessible
Last modified: 2017-04-04 02:09:04 EDT
Description of problem:
With Fedora's Beaker instance which I believe has a different public and private hostnames, the task RPM URL when retrieved via XML-RPC returns the private URL and not the public one. On the task page in the Web UI, the URL is correctly the public facing URL.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Visit Fedora project's beaker instance
2. Check any task's URL
3. Retrieve the XML for this task and check the URL
Perhaps, the absolute_url() in model.py needs to be looked into.
For example, for a task, it's XML returns:
<task version="1.2-50" name="/distribution/pkginstall" creation_date="2013-09-04 00:14:40">
<description>Reports back on the package \tinstallation that was done</description>
<owner>Gurhan Ozen <firstname.lastname@example.org></owner>
<rpms><rpm url="http://beaker01.qa.fedoraproject.org/bkr/rpms/rh-tests-distribution-pkginstall-1.2-50.noarch.rpm" name="rh-tests-distribution-pkginstall-1.2-50.noarch.rpm"/></rpms>
On the Web UI, the URL is rightly: http://beaker.fedoraproject.org/rpms/rh-tests-distribution-pkginstall-1.2-50.noarch.rpm
Made the example public, since my understanding is that the private Fedora URLs are private in the "unroutable" sense, rather than the "secret" sense :)
This is actually an interesting problem, since I believe what Beaker is currently doing is *right* from a test execution point of view - tasks running on the lab controller need to see the private URL, as they may not have access to the public one, and they're the most likely consumers of the task library URLs.
So it's not as simple as saying "everything should use the public URL", since the test systems may not be able to access that.
Always using the private URL isn't right either, since external clients may want to be able to retrieve the task RPMs (e.g. the task sync script).
Detecting which IP address or URL was used to access the site isn't feasible for XML-RPC, but *would* be feasible for a REST API. So the answer may be to expose a REST API for the task library, rather than trying to fix the XML-RPC API.
Updating description to reflect the fact that everything pretty much works here, there is only quite a narrow case that is problematic: when you have a Beaker instance with tg.lab_domain set to some hostname not resolvable on the internet, and someone on the internet wants to run beaker-sync-tasks pointing at your Beaker. In that case the task XML will have inaccessible URLs in it.
beaker-sync-tasks is the only known consumer of the task XML apart from the harness.