Mark Cornmesser [:markco] OOO 2024/04/15 Assignee
	Description • 9 years ago

      No description provided.

	Dustin J. Mitchell [:dustin] (he/him)
	Comment 3 • 9 years ago

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?

	Mark Cornmesser [:markco] OOO 2024/04/15 Assignee
	Comment 4 • 9 years ago

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']
        }

	Dustin J. Mitchell [:dustin] (he/him)
	Comment 5 • 9 years ago

Yep!

	Mark Cornmesser [:markco] OOO 2024/04/15 Assignee
	Comment 6 • 9 years ago

Comment on attachment 8627834 [details] [diff] [review]
Bug1170588.patch

https://hg.mozilla.org/build/puppet/rev/3525155e478c

	Mark Cornmesser [:markco] OOO 2024/04/15 Assignee
	Comment 7 • 9 years ago

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

	Mark Cornmesser [:markco] OOO 2024/04/15 Assignee
	Comment 8 • 9 years ago

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

	Dustin J. Mitchell [:dustin] (he/him)
	Comment 9 • 9 years ago

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 :)

	Mark Cornmesser [:markco] OOO 2024/04/15 Assignee
	Comment 10 • 9 years ago

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.

	Mark Cornmesser [:markco] OOO 2024/04/15 Assignee
	Comment 11 • 9 years ago

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

	Mark Cornmesser [:markco] OOO 2024/04/15 Assignee
	Comment 12 • 9 years ago

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.

	Mark Cornmesser [:markco] OOO 2024/04/15 Assignee
	Comment 13 • 9 years ago

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.

	Dustin J. Mitchell [:dustin] (he/him)
	Comment 15 • 9 years ago

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?

	Mark Cornmesser [:markco] OOO 2024/04/15 Assignee
	Comment 16 • 9 years ago

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.

	Mark Cornmesser [:markco] OOO 2024/04/15 Assignee
	Comment 17 • 9 years ago

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

	Amy Rich [:arr] [:arich]
	Comment 18 • 9 years ago

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]

	Mark Cornmesser [:markco] OOO 2024/04/15 Assignee
	Comment 19 • 9 years ago

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.

	Rob Thijssen [:grenade (EET/UTC+0300)]
	Comment 20 • 9 years ago

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.

	Mark Cornmesser [:markco] OOO 2024/04/15 Assignee
	Comment 21 • 9 years ago

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

	Rob Thijssen [:grenade (EET/UTC+0300)]
	Comment 22 • 9 years ago

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.

	Rob Thijssen [:grenade (EET/UTC+0300)]
	Comment 23 • 9 years ago

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).

	Mark Cornmesser [:markco] OOO 2024/04/15 Assignee
	Comment 24 • 9 years ago

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.

	Rob Thijssen [:grenade (EET/UTC+0300)]
	Comment 25 • 9 years ago

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.

	Mark Cornmesser [:markco] OOO 2024/04/15 Assignee
	Comment 26 • 9 years ago

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?

	Rob Thijssen [:grenade (EET/UTC+0300)]
	Comment 28 • 9 years ago

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.

	Mark Cornmesser [:markco] OOO 2024/04/15 Assignee
	Comment 29 • 9 years ago

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

	Rob Thijssen [:grenade (EET/UTC+0300)]
	Comment 30 • 9 years ago

Comment on attachment 8641490 [details] [diff] [review]
Bug1170588_2.patch

Review of attachment 8641490 [details] [diff] [review]:
-----------------------------------------------------------------

meh