Comment on attachment 8627834 [details] [diff] [review] Bug1170588.patch Review of attachment 8627834 [details] [diff] [review]: ----------------------------------------------------------------- ::: modules/packages/manifests/mozilla/py27_mercurial.pp @@ +60,5 @@ > + exec { "Mercurial-3.2.1": > + command => "C:\\installersource\\puppetagain.pub.build.mozilla.org\\EXEs\\Mercurial-3.2.1-x64.exe /VerySilent /SUPPRESSMSGBOXES /DIR=C:\\mozilla-build\\hg", > + subscribe => Exec["remove_old_hg"], > + creates => "C:\\mozilla-build\\hg\\MPR.dll", > + } -> Anchor['packages::mozilla::py27_mercurial::end'] Indentation is wrong here, and the -> relationship is missing between the file and exec resources. Just putting `->` between the `}` and `exec {` should do the trick. Is this a file/exec instead of a pkgexe because pkgexe doesn't take parameters? Or something else?

Yes using the file/exec because pkgexe wasn't accepting parameters. Does this look correct: Windows: { $mercurial = 'C:\mozilla-build\hg\hg.exe' include packages::mozilla::mozilla_build Anchor['packages::mozilla::py27_mercurial::begin'] -> file { "C:/installersource/puppetagain.pub.build.mozilla.org/EXEs/Mercurial-3.2.1-x64.exe" : ensure => file, source => "puppet:///repos/EXEs/Mercurial-3.2.1-x64.exe", } -> exec { "Mercurial-3.2.1": command => "C:\\installersource\\puppetagain.pub.build.mozilla.org\\EXEs\\Mercurial-3.2.1-x64.exe /VerySilent /SUPPRESSMSGBOXES /DIR=C:\\mozilla-build\\hg", subscribe => Exec["remove_old_hg"], creates => "C:\\mozilla-build\\hg\\MPR.dll", } -> Anchor['packages::mozilla::py27_mercurial::end'] }

Yep!

Comment on attachment 8627834 [details] [diff] [review] Bug1170588.patch https://hg.mozilla.org/build/puppet/rev/3525155e478c

Reopening due to failures: Tue Jul 07 14:24:59 -0700 2015 Puppet (err): Command exceeded timeout Tue Jul 07 14:24:59 -0700 2015 /Stage[main]/Packages::Mozilla::Py27_mercurial/Exec[Mercurial-3.2.1]/returns (err): change from notrun to 0 failed: Command exceeded timeout and once: Tue Jul 07 11:19:10 -0700 2015 Puppet (err): Could not retrieve catalog from remote server: Error 400 on SERVER: cannot install on windows at /etc/puppet/production/modules/mercurial/manifests/settings.pp:12 on node b-2008-ix-0078.winbuild.releng.scl3.mozilla.com Tue Jul 07 11:19:10 -0700 2015 Puppet (err): Could not retrieve catalog; skipping run

In a fresh environment on first run the second errors occurs.

For the first, you may need to increase the exec timeout for that exec -- although I wonder why it's taking so long. Is it prompting onscreen or something? For the second, indeed the 'mercurial' module claims to not support Windows. Which means that at one point this module was not included on Windows, and now it is. It looks like http://hg.mozilla.org/build/puppet/diff/383182f141f9/modules/users/manifests/builder/setup.pp is responsible for that -- so I'll leave it to you and catlee as to who needs to fix :)

The error that causes the puppet timeout is odd. It only occurs on the first run through MDT. The timeout does not occur on first run in AWS. And even though it times out it still installs.

There are 2 process spawned Mercurial-3.2.1-x64.exe and Mercurial-3.2.1-x64.tmp.

The install, when initialized by the scripted Puppet run, is hanging while trying to execute C:\mozilla-build\hg\add_path.exe. It hangs long enough for the process to timeout. When it times out the window shown in the attachment hg_timeout.jpg is launched and requires human interaction. When there is no human interaction, Puppet eventual times out because it never gets a return to the exec. Since this is only temporary until we have Windows package management in place and because of the urgency to get Puppet configured 2008 going, I am going try to use schtasks to run the install.

Using schtasks through Puppet yields the same timeout window, but does not cause Puppet to time out. The installation itself appears to be complete, and failing to append the path should not be an issue since the path is appended and changed during the build process.

Comment on attachment 8638011 [details] [diff] [review] Bug1170588.patch Review of attachment 8638011 [details] [diff] [review]: ----------------------------------------------------------------- So basically the scheduled task can be deleted despite the window remaining up? ::: modules/packages/manifests/mozilla/py27_mercurial.pp @@ +64,5 @@ > source => "puppet:///repos/EXEs/Mercurial-3.2.1-x64.exe", > + } -> exec { "Schtasks_Mercurial-3.2.1": > + command => '"C:\Windows\system32\schtasks.exe" /create /sc once /st 23:59 /tn hg_3-2-1 /tr "C:\installersource\puppetagain.pub.build.mozilla.org\EXEs\Mercurial-3.2.1-x64.exe /SILENT /DIR=C:\mozilla-build\hg"', > + require => Exec["remove_old_hg"], > + creates => "C:\\mozilla-build\\hg\\MPR.dll", How does adding a scheduled task create a DLL?

The schedule task will delete with the remaining open. The schedule task does not create the dll. I am using it as a marker to start the whole installation process.

Comment on attachment 8638011 [details] [diff] [review] Bug1170588.patch https://hg.mozilla.org/build/puppet/rev/dc2952d8ca6b https://hg.mozilla.org/build/puppet/rev/0426a923bb73

This appears to be failing on at least some hosts: Wed Jul 29 12:48:40 -0700 2015 Puppet (err): "C:\Windows\system32\schtasks.exe" /create /sc once /st 23:59 /tn hg_3-2-1 /tr "C:\installersource\puppetagain.pub.build.mozilla.org\EXEs\Mercurial-3.2.1-x64.exe /SILENT /DIR=C:\mozilla-build\hg" returned 1 instead of one of [0] Wed Jul 29 12:48:40 -0700 2015 /Stage[main]/Packages::Mozilla::Py27_mercurial/Exec[Schtasks_Mercurial-3.2.1]/returns (err): change from notrun to 0 failed: "C:\Windows\system32\schtasks.exe" /create /sc once /st 23:59 /tn hg_3-2-1 /tr "C:\installersource\puppetagain.pub.build.mozilla.org\EXEs\Mercurial-3.2.1-x64.exe /SILENT /DIR=C:\mozilla-build\hg" returned 1 instead of one of [0]

This is seems to be failing on the creation of the schedule task in AWS, so suspect that it may be trying to create it for the user that is executing the EC2 userdata. I am adding the ru flag to the creation command to have it run as System. After a handful of runs I have not seen this failure pop back up.

i got to thinking and testing to try and understand why your earlier implementation would not silent install and found some documentation (http://jrsoftware.org/ishelp/topic_setupcmdline.htm) that mentions another switch '/SP-' to disable prompts. when i added this switch and tested in ec2 (b-2008-ec2-grenade), i got a silent install using the attached patch. i wonder if it makes sense to go back to the simpler version and just add the switch.

I will try it through MDT. Previously I tried the "/SUPPRESSMSGBOXES" flag, and the error Window error still opened that kills the MDT run.

looking at the doc linked above, you'll still need that. it's a pretty crappy installer that needs three separate, stfu-and-silent-install-already parameters, in order to silent install, but i reckon with all three (/verysilent /suppressmsgboxes /sp-) you should get what you need.

oh and also in the docs, it looks like these would still fail if a pre-existing file has to be overwritten, so it may require a wipe of the target path first if you expect c:/mozilla-build/hg/anything to exist already (not the case in ec2).

HG gets installed and then removed from that location: http://hg.mozilla.org/build/puppet/file/a3b1ae943ba4/modules/packages/manifests/mozilla/mozilla_build.pp Because it is part of the original Mozilla Build package.

yuck! but at least it means you can ignore comment 23. because the ec2 test run from b-2008-ec2-grenade was successful with the 3 stfu switches. so if overwriting happened, it happened quietly. in my patch, there is also a /log=c:/log/hg-install.log switch, which i added to make it obvious whats failing, if somethings failing.

I made some changes and running this command: "C:\\installersource\\puppetagain.pub.build.mozilla.org\\EXEs\\Mercurial-3.2.1-x64.exe /SP- /VerySilent /SUPPRESSMSGBOXES /DIR=C:\\mozilla-build\\hg /LOG=C:\\programdata\\puppetagain\\hg-install.log", As well as adding a /c to the remove old hg exec in mozilla_build.pp. Puppet itself does not throw an error or warning, but MDT does fail out. The error window pops when add-path.exe is being executed. Rob: Any suggestions?

I have no suggestions that I like. The only thing I can think is that if the puppet install succeeds, with the exception of the add_path bit, is to just do the add path bit as a separate thing in puppet (eg: set path the normal way with `setx PATH %PATH%;C:\mozilla-build\hg`) But that's just as hacky as the other workaround with a scheduled task. I'm at a loss, really. It's a cr@ppy installer.

I think we should move forward the schedule task hack and then revisit this once we get to Windows package management.

Comment on attachment 8641490 [details] [diff] [review] Bug1170588_2.patch Review of attachment 8641490 [details] [diff] [review]: ----------------------------------------------------------------- meh