Bug 969962

Please consider patches

--- /usr/bin/rhts-environment.sh.orig	2013-04-05 02:55:07.000000000 -0400
+++ /usr/bin/rhts-environment.sh	2013-05-30 13:22:20.481051448 -0400
@@ -30,6 +30,13 @@
    HOSTNAME=$(hostname)
 fi 
 
+if [ -f /etc/original-hostname ]; then
+	export ORIGINAL_HOSTNAME=$( cat /etc/original-hostname )
+else
+	export ORIGINAL_HOSTNAME=$HOSTNAME
+	echo $ORIGINAL_HOSTNAME > /etc/original-hostname
+fi
+
 if [ -z "$ARCH" ]; then
         ARCH=$(uname -i)
 fi
--- /usr/bin/rhts-sync-set.orig	2013-04-05 02:55:07.000000000 -0400
+++ /usr/bin/rhts-sync-set	2013-05-30 13:24:16.242686978 -0400
@@ -80,7 +80,9 @@
         recipesetid = os.environ['RECIPESETID']
     if ('TESTORDER' in os.environ.keys()):
         testorder = os.environ['TESTORDER']
-    if ('HOSTNAME' in os.environ.keys()):
+    if ('ORIGINAL_HOSTNAME' in os.environ.keys()):
+        hostname = os.environ['ORIGINAL_HOSTNAME']
+    elif ('HOSTNAME' in os.environ.keys()):
         hostname = os.environ['HOSTNAME']
 
     args = sys.argv[1:]

which "fixates" the original HOSTNAME in the ORIGINAL_HOSTNAME variable and uses that variable as the default hostname in rhts-sync-set.

Note that this also makes it much easier to check if the machine is part of some role (SERVERS, CLIENTS, whatever you put to the role attribute) by using $ORIGINAL_HOSTNAME while using $HOSTNAME or $(hostname) no longer works.

I might have needed the patch

--- /usr/lib/python2.6/site-packages/beah/tasks/rhts_xmlrpc.py.orig	2013-04-05 02:43:26.000000000 -0400
+++ /usr/lib/python2.6/site-packages/beah/tasks/rhts_xmlrpc.py	2013-05-31 05:28:09.676218239 -0400
@@ -288,7 +288,7 @@
 
     def __init__(self, main):
         self.main = main
-        self.localhosts = (main.env.get('HOSTNAME', ''), os.environ.get('HOSTNAME', ''))
+        self.localhosts = (main.env.get('HOSTNAME', ''), os.environ.get('HOSTNAME', ''), os.environ.get('ORIGINAL_HOSTNAME', ''))
 
     def trhostname(self, hostname):
         if hostname in self.localhosts:

in the past as well but I'm not 100 % sure about that -- I assume developers fluent in the beah code should know for sure.

Thanks for the ideas/patches Jan. I think they sound good in theory.

Many tasks are using $HOSTNAME but it's problematic because (a) it's bash-specific, (b) it's set once to whatever the hostname was at the time the shell started, (c) it's *not* the fully-qualified domain name, unless the DHCP config has caused the hostname to be set to a FQDN (which is not always the case).

A better option is $(hostname -f) but as you point out in this bug, very often what the task really wants is the hostname from Beaker's point of view, not whatever glibc thinks the current DNS FQDN is.

I wonder if $BEAKER_HOSTNAME might be a better name than $ORIGINAL_HOSTNAME. We need to consider how it fits in with the other environment variables defined by Beaker.

(In reply to Dan Callaghan from comment #4)
> 
> I wonder if $BEAKER_HOSTNAME might be a better name than $ORIGINAL_HOSTNAME.
> We need to consider how it fits in with the other environment variables
> defined by Beaker.

Sure, BEAKER_HOSTNAME will do just as well.

*** Bug 1045010 has been marked as a duplicate of this bug. ***

Closing the issue due to better harness available. Please use Restraint for your testing purposes. Feel free to reopen if you have the same issue with Restraint as well.