Problem with qube and dhcp

[arenyart]

I am having a strange problem that probably has a simple solution (that I can't seem to find).  Basically, we have removed some old machines and added some new ones.  The new machines are supposed to be on a separate group but one of them is getting confused with the settings from an old machine because it is using the same DHCP assigned IP address.  I did an upgrade_supervisor --reset which reset the job database, but it didn't reset the worker database, so the problem persists.  My question is two fold. First, is it a bad idea to use dhcp instead of static ip?  Second, is there an easy way to flush the worker part of the database?  Thank you in advance for any help you can provide.

[anthony]

Hey arenyart,

    Qube! itself uses Mac Addresses to identify workers.  How are you configuring your workers?  are you using the qbwrk.conf method? or are you configuring each worker individually?

    As far as DHCP is concerned, Qube! is completely ok with using a DHCP ip address scheme.

    Thanks,
          A.

[arenyart]

Yes, I am using qbwrk.conf to configure the workers.  The problem only seems to happen with 64bit nodes (Windows xp 64).  I only guessed that it was a dhcp issue because the machine having the issue was using the same ip as a machine that was down at the time (but still listed in the worker tab in the gui).  I reinstalled qube on the supervisor.  I even deleted the old install folder before reinstallation, so I don't think it is an artifact in a database.  Is there some kind of cache that tracks mac addresses based on ip address. Could that possibly cause this confusion?  Or could this be a 64bit bug or some sort?  I am currently using Windows server 2003 (32bit) for the supervisor, and have a mix of 32bit and 64bit rendernodes (all windows xp.  The 32bit machines seem to do fine.  I have the most problems with the higher end 64bit machines.  We are using Qube 5.2.1 on all machines. 

[anthony]

Hey arenyart,

    Ah ok, that makes more sense to me now.  Using upgrade_supervisor --reset literally blows away the entire database.  Qube! doesn't use any other mechanism to store stateful data.  So by using the command, you've already toasted all of the supervisor's internal caches.

    Given that you're using the qbwrk.conf to configure your hosts, I'm assuming that your configuring using the host's name.  If you would like us to review the settings, you're free to post the file here, or if you want we can switch to support@pipelinefx.com which is easier to keep confidential.

    A.

[arenyart]

Could the problem be that some of the machines in the qbwrk.conf file are currently down?  Should I take those off the config and then reconfigure workers?

Here is my qbwrk.conf file: (The "orl" machines are the 64bit ones with the problems)

[3dh_cluster]
worker_port = 50011
worker_cpus = 0
worker_flags = auto_mount, remove_logs,load_profile
worker_cluster = 3dh
worker_groups = 3dhGroup
proxy_account =removed for privacy
proxy_execution_mode = proxy
proxy_password = removed for privacy

[atlrender001] : 3dh_cluster
[atlrender002] : 3dh_cluster
[atlrender003] : 3dh_cluster
[atlrender004] : 3dh_cluster
[atlrender005] : 3dh_cluster
[atlrender006] : 3dh_cluster
[atlrender007] : 3dh_cluster
[atlrender008] : 3dh_cluster
[atlrender009] : 3dh_cluster
[atlrender010] : 3dh_cluster
[atlrender011] : 3dh_cluster
[atlrender012] : 3dh_cluster
[atlrender013] : 3dh_cluster
[atlrender014] : 3dh_cluster
[atlrender015] : 3dh_cluster

[renderdell001] : 3dh_cluster
[renderdell002] : 3dh_cluster
[renderdell003] : 3dh_cluster
[renderdell004] : 3dh_cluster
[renderdell005] : 3dh_cluster
[renderdell006] : 3dh_cluster
[renderdell007] : 3dh_cluster
[renderdell008] : 3dh_cluster
[renderdell009] : 3dh_cluster
[renderdell010] : 3dh_cluster
[renderdell011] : 3dh_cluster
[renderdell012] : 3dh_cluster
[renderdell013] : 3dh_cluster
[renderdell014] : 3dh_cluster
[renderdell015] : 3dh_cluster
[renderdell016] : 3dh_cluster


[orl_cluster]
worker_port = 50011
worker_cpus = 0
worker_flags = auto_mount,remove_logs,load_profile
worker_cluster = orl
worker_groups = orlGroup
proxy_account = removed for privacy
proxy_execution_mode = proxy
proxy_password = removed for privacy

[orlrndrnde001] : orl_cluster
[orlrndrnde002] : orl_cluster
[orlrndrnde003] : orl_cluster

[anthony]

Hey arenyart,

    Skimming through the qbwrk.conf file, it occurs to me that you guys might be using a windows DNS server which allows hostname registration through DCHP.  If you were to ping the old worker you're talking about, can you still get a reply on the supervisor? 

    A.