And in case it's not clear, the finish scripts and user-data both make a foreman_url('built') call. This should be isolated.

Stephen Benjamin wrote:

And in case it's not clear, the finish scripts and user-data both make a foreman_url('built') call. This should be isolated.

finish scripts used for image builds should not call foreman_url for anything (https://github.com/theforeman/community-templates/blob/master/kickstart/finish.erb doesn't), as the finish script is called synchronously from Foreman. Calling foreman_url blindly may cause issues like #9098 ('built' is probably OK). finish scripts used with preseed should call foreman_url, as they're asynchronous.

user-data files/scripts should also call it.

So, we can't use any clever tricks in this case. The usual case (i.e PXE-based installs) is that we have a TFTP proxy we can qury to see if it also has the Template feature, and make use of it if so. In the Openstack case, it's quite possible the host has no proxies assigned (i.e if you're not using DNS or Puppet/PuppetCA).

So, the only solution I can think of is to add a new field to the Operating System partials which is a combobox containing all known Template Proxies (and hide it if template_proxies.size == 0). We'll have to store this in the DB (on the hosts table) so that it's consistent when editing the host. We'll probably want a JS/AJAX call to pre-populate it with the appropriate proxy if a subnet is selected. Once submitted, the renderer(s) will need to use that field instead of the current guesswork around TFTP proxies.

This will have the bonus side-effect of fixing the issue when the TFTP proxy and the Template proxy are not the same entity.