Description of problem: Condor packages for Windows do not download the "wallaby_node.config" file, if installation is clear (the previous stable version is uninstalled). The Central manager is able to see the Windows node (see the terminal transcript below, please). If the condor packages are only updated from the previous version (in this case condor-7.8.7-0.6.msi), the "wallaby_node.config" file is downloaded; even if the file was deleted. In the both cases the firewall rules are set identically. Version-Release number of selected component (if applicable): Windows machine: condor-7.8.8-0.4.3.msi Central manager: [root@dhcp-lab-121 ~]# rpm -qa | egrep '(condor|wallaby)' condor-low-latency-1.2-3.el6.noarch condor-aviary-7.8.8-0.4.3.el6_4.x86_64 condor-job-hooks-1.5-6.el6.noarch condor-wallaby-base-db-1.25-1.el6_3.noarch condor-vm-gahp-7.8.8-0.4.3.el6_4.x86_64 python-condorec2e-1.3.0-3.el6.noarch condor-wallaby-tools-5.0.5-2.el6.noarch python-condorutils-1.5-6.el6.noarch condor-ec2-enhanced-1.3.0-2.el6.noarch python-wallabyclient-5.0.5-2.el6.noarch condor-7.8.8-0.4.3.el6_4.x86_64 condor-plumage-7.8.8-0.4.3.el6_4.x86_64 condor-deltacloud-gahp-7.8.8-0.4.3.el6_4.x86_64 condor-debuginfo-7.8.8-0.4.3.el6_4.x86_64 wallaby-utils-0.16.3-1.el6.noarch wallaby-0.16.3-1.el6.noarch ruby-condor-wallaby-5.0.5-2.el6.noarch condor-classads-7.8.8-0.4.3.el6_4.x86_64 condor-cluster-resource-agent-7.8.8-0.4.3.el6_4.x86_64 condor-classads-devel-7.8.8-0.4.3.el6_4.x86_64 python-wallaby-0.16.3-1.el6.noarch condor-qmf-7.8.8-0.4.3.el6_4.x86_64 ruby-wallaby-0.16.3-1.el6.noarch condor-wallaby-client-5.0.5-2.el6.noarch condor-kbdd-7.8.8-0.4.3.el6_4.x86_64 condor-ec2-enhanced-hooks-1.3.0-3.el6.noarch How reproducible: 100% Steps to Reproduce: 1. Uninstall condor from the Windows machine (if any condor version is installed) 2. Open the condor installation wizard and install condor. 3. Restart the machine and wait for condor service starting. Actual results: The condor service on the Windows machine starts, but it does not download the "wallaby_node.config" file from the central manager. Expected results: The "wallaby_node.config" file should be downloaded from the central manager to the Windows node after starting the condor service. Additional info: Central manager terminal transcript: [root@dhcp-lab-121 wallaby]# condor_status Name OpSys Arch State Activity LoadAv Mem ActvtyTime slot10@dhcp-lab-12 LINUX X86_64 Unclaimed Idle 0.000 175 0+00:50:07 slot11@dhcp-lab-12 LINUX X86_64 Unclaimed Idle 0.000 175 0+00:50:08 slot12@dhcp-lab-12 LINUX X86_64 Unclaimed Idle 0.000 175 0+00:50:09 slot13@dhcp-lab-12 LINUX X86_64 Unclaimed Idle 0.000 175 0+00:50:11 slot14@dhcp-lab-12 LINUX X86_64 Unclaimed Idle 0.000 175 0+00:50:10 slot15@dhcp-lab-12 LINUX X86_64 Unclaimed Idle 0.000 175 0+00:50:11 slot16@dhcp-lab-12 LINUX X86_64 Unclaimed Idle 0.000 175 0+00:50:04 slot1@dhcp-lab-121 LINUX X86_64 Unclaimed Idle 0.270 175 0+00:49:50 slot2@dhcp-lab-121 LINUX X86_64 Unclaimed Idle 0.000 175 0+00:50:07 slot3@dhcp-lab-121 LINUX X86_64 Unclaimed Idle 0.000 175 0+00:50:08 slot4@dhcp-lab-121 LINUX X86_64 Unclaimed Idle 0.000 175 0+00:50:09 slot5@dhcp-lab-121 LINUX X86_64 Unclaimed Idle 0.000 175 0+00:50:11 slot6@dhcp-lab-121 LINUX X86_64 Unclaimed Idle 0.000 175 0+00:50:11 slot7@dhcp-lab-121 LINUX X86_64 Unclaimed Idle 0.000 175 0+00:50:12 slot8@dhcp-lab-121 LINUX X86_64 Unclaimed Idle 0.000 175 0+00:50:05 slot9@dhcp-lab-121 LINUX X86_64 Unclaimed Idle 0.000 175 0+00:50:06 2008-x64-1 WINDOWS X86_64 Owner Idle 0.020 1022 0+00:00:09 [root@dhcp-lab-121 wallaby]# condor_configure_pool --list-all-nodes Console Connection Established... dhcp-lab-121.englab.brq.redhat.com 2008-r2-1 7-x64-1 7-x86-1 xp-x86-1 2003-x64-1 2008-x64-1 s2008-x86-1 2003-x86-1
Yes, this is regression because we test this for every version tested on Windows. It works in 2.3.
Could you please denote any missing files in the package 2.3.5 package, that was in the 2.3 package. I suspect there is a packaging issue.
Missing files in condor-7.8.8-0.4.3.msi (compared with condor-7.8.7-0.6.msi - should be 2.3 version): \bin\boost_date_time-vc90-mt-1_39.dll \bin\boost_filesystem-vc90-mt-1_39.dll \bin\boost_program_options-vc90-mt-1_39.dll \bin\boost_regex-vc90-mt-1_39.dll \bin\boost_system-vc90-mt-1_39.dll \bin\boost_thread-vc90-mt-1_39.dll \bin\site-packages\qmf2-prototype\__init__.py \bin\site-packages\qmf2-prototype\agent.py \bin\site-packages\qmf2-prototype\common.py \bin\site-packages\qmf2-prototype\console.py \bin\site-packages\qmf2-prototype\tests\__init__.py \bin\site-packages\qmf2-prototype\tests\agent_discovery.py \bin\site-packages\qmf2-prototype\tests\agent_test.py \bin\site-packages\qmf2-prototype\tests\async_method.py \bin\site-packages\qmf2-prototype\tests\async_query.py \bin\site-packages\qmf2-prototype\tests\basic_method.py \bin\site-packages\qmf2-prototype\tests\basic_query.py \bin\site-packages\qmf2-prototype\tests\console_test.py \bin\site-packages\qmf2-prototype\tests\events.py \bin\site-packages\qmf2-prototype\tests\multi_response.py \bin\site-packages\qmf2-prototype\tests\obj_gets.py \bin\site-packages\qmf2-prototype\tests\subscriptions.py \bin\site-packages\qmf\__init__.py \bin\site-packages\qmf\console.py \condor-7.8.7-0.6.msi Complete list of included files is attached.
Created attachment 774694 [details] Content of condor-7.8.8-0.4.3.msi package compared with condor-7.8.7-0.6.msi
The issue seems to be fixed in condor-win-7.8.8-0.4.4 (it did not occur on any machine), but this bz is still ASSIGNED and has devel_ack-. Tim, could you possibly look at it, please? Can I verify it?
This bug does not occur in any supported Windows platform: - Windows7-x86 and x64 - WindowsXP-x86 - Windows Server2003-x86 and x64 - Windows Sever2008-x86, x64 and R2 Verified on packages condor-win-7.8.8-0.4.4.msi --> VERIFIED
MRG-G is in maintenance only and only customer escalations will be addressed from this point forward. This issue can be re-opened if a customer escalation associated with this issue occurs.