Bug 5738 - Exception: hostname None already present
: Exception: hostname None already present
Status: RESOLVED FIXED
: Nimbus
Workspace service
: TP1.3.0
: All All
: P3 normal
: ---
Assigned To:
:
:
:
:
  Show dependency treegraph
 
Reported: 2007-12-18 18:06 by
Modified: 2008-02-13 12:42 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2007-12-18 18:06:54
I'm attempting to create multiple VMs using "none" for hostname, which appears
to be supported from comments in the sample association file.


    globus@syracuse:~$ cat
/usr/local/globus-4.0.5/etc/workspace_service/associations/lesbos | grep
hostname
    # If hostname is 'none' it is not assigned.

    globus@syracuse:~$ tail -1
/usr/local/globus-4.0.5/etc/workspace_service/associations/lesbos
    none 192.168.15.181 192.168.15.1 192.168.15.255 255.255.255.0
    globus@syracuse:~$ tail -1
/usr/local/globus-4.0.5/etc/workspace_service/associations/sicily 
    none 192.168.15.171 192.168.15.1 192.168.15.255 255.255.255.0


But this fails:


root@greece:/opt/workspace-TP1.3.0# tail -30
logs/Dec-18-2007-15:07:13-workspace-28-create
  subnetmask: 255.255.255.0
     gateway: 192.168.15.1
    hostname: None
        dns1: none
        dns2: none
CMD: bash /opt/workspace-TP1.3.0/bin/ebtables-config.sh add workspace-28-1
vif0.0 AA:01:7C:FE:03:57 192.168.15.171
  subcommand: add
     vifname: workspace-28-1
      dhcpif: vif0.0
     macaddr: AA:01:7C:FE:03:57
      ipaddr: 192.168.15.171
Chain DHCP-vif0.0 already exists.
Created workspace-28-1 chain
Added workspace-28-1 FORWARD rule
ebtables addition succeeded
CMD: /etc/init.d/dhcp stop
Stopping DHCP server: dhcp.
CMD: python /opt/workspace-TP1.3.0/bin/dhcp-conf-alter.py -a -i 192.168.15.171
-m AA:01:7C:FE:03:57 -n None -p /etc/dhcpd.conf -b 192.168.15.255 -s
255.255.255.0 -g 192.168.15.1
ERROR: Problem:
Traceback (most recent call last):
  File "/opt/workspace-TP1.3.0/bin/dhcp-conf-alter.py", line 629, in run
    add(opts, conf)
  File "/opt/workspace-TP1.3.0/bin/dhcp-conf-alter.py", line 154, in add
    conf.add(entry)
  File "/opt/workspace-TP1.3.0/bin/dhcp-conf-alter.py", line 83, in add
    raise Exception("hostname %s already present" % entry.hostname + ",
allhosts %s" % self.all_hosts)
Exception: hostname None already present, allhosts {'192.168.15.181':
<__main__.DHCPConfEntry instance at 0x821eaec>}
ERROR: dhcp policy addition failed
CMD: /etc/init.d/dhcp start
Starting DHCP server: dhcpd failed to start - check syslog for diagnostics.


This check in "dhcp-conf-alter.py" is missed, since hostname is the string
"None" when specified on the command-line by the WS layer:

    393         if not opts.hostname:
    394             raise InvalidInput("Add requires a hostname, see help
(-h).")
    395         else:
    396             log.debug("    hostname = %s" % opts.hostname)


Obviously the intent was to not handle "None", but the first VM will deploy.

The web services layer shouldn't pass this "-n None", it should leave it
unspecified and allow the backend to perform it's check and bubble up the error
information.
------- Comment #1 From 2007-12-18 18:29:00 -------
I looked into this a bit, the underlying problem would indeed have been caught
if the none string was interpreted correctly at higher layers.

The underlying problem here is that the dhcpd.conf syntax will not allow "no
hostname" and our code checks for this and does not allow no hostname.  When I
coded the DHCP mechanisms it was an oversight not to realize that the
advertisement in the config file that association entries can exist without
corresponding hostnames is now wrong.

We could either require the administrator to enter hostnames for each address
or perhaps create a UUID on the fly if there is no hostname specified (the idea
being that the admin is already OK with the absence of any DNS mapping anywhere
for the address(es) in question).

First, I am going to experiment to double check ISC dhcpd will indeed not
deliver a lease without hostname (this is the way 'man dhcpd.conf' reads).
------- Comment #2 From 2008-02-13 12:42:47 -------
This is fixed in TP1.3.1, hostnames are now required in the network pool
configs.  Thanks Josh.