Problems invoking puppet-masterless after using scripts/puppet.bat

[raniemi]

What I'm trying to do is repurpose the windows_2008_r2.json file by swapping out scripts/chef.bat for scripts/puppet.bat and then calling out to puppet-masterless to install and run my manifests.

The scripts/puppet.bat file is being executed and puppet is being installed correctly. However, once puppet apply is invoked by puppet-masterless the execute_command is shown, but my manifest is not being executed and no additional output/errors are shown (even with PACKER_LOG=1 set).

For testing purposes, I have been using the following custom execute_command:

"execute_command": " \
    {{.FacterVars}}puppet apply \
        --debug \
        --logdest='C:/Windows/Temp/puppet-apply.log' \
        --modulepath='{{.ModulePath}}' \
        --manifestdir='{{.ManifestDir}}' \
        --detailed-exitcodes \
        -e 'include rubyinstaller' \
"

NOTES:

• The spacing and EOL \s were added here for readability purposes only
• I am using packer 0.5.2
• When the execute_command "runs", the logdest file does not get created
• I have even tried specifying the absolute path to puppet's bat file under Program Files just in case the guest OS PATH was not visible at the time puppet-masterless ran -- no effect
• When I pause packer after the puppet-masterless step and I execute the generated execute_command at the guest Windows VM's command prompt, the execution works.
• The (custom) "rubyinstaller" module that I'm using is attempting to install rubyinstaller in "verysilent" mode. Has anyone seen any limitations with puppet-masterless when using an installer on windows that requires a desktop?
• I've also noticed on Windows with packer that if puppet apply fails or a shell script returns a non-zero ERRORLEVEL, packer keeps on going. Any suggestions on how to fail-fast? (EDIT: this bullet looks suspiciously like fix passing exit status from shell provision to packer #45)
• I only know this from the occasional warning that I'm seeing, but It appears that cygwin is being used under the covers by puppet-masterless. Any other gotchas I should keep in mind when working with custom execute_commands?

I realize that some of these questions may be best asked on the packer forum, but since these questions are very windows specific, I'm wondering if other trailblazers here have already encountered and resolved these issues.

[raniemi]

I still have not been successful with using puppet-masterless to execute my manifest files (just on windows, no issues on Linux). Furthermore, I still can't seem to get any additional output when calling puppet-masterless that I can use for debugging.

In absence of a good solution, I applied the following dirty, dirty hack:

• I'm still using puppet-masterless to stage the manifests and modules on the guest Windows VM
• I've overridden the execute_command for puppet-masterless as follows:

"execute_command": "echo 'Deferring puppet apply'",

• Right after the puppet-masterless provisioner step I have a shell provisioner that calls out to a batch file that invokes puppet apply.

Hopefully this hack is helpful for others who get stuck. I'm looking forward to the day that I can just drop the extra shell provisioner and just use the puppet-masterless provisioner.

[joefitzgerald]

Interesting - you've done some good digging on this. Have you tried running packer with the -debug flag in addition to PACKER_LOG=1? This smells like a Windows compatibility issue with Packer, so you should consider opening an issue over there also and referencing back to this.

Regarding the shell return code issue, it does sound related to #45.

Regarding cygwin, from http://sshwindows.sourceforge.net:

OpenSSH for Windows is a free package that installs a minimal OpenSSH server and client utilities in the Cygwin package without needing the full Cygwin installation.

[raniemi]

Thanks Joe for the background on OpenSSH for Windows and reminding me about the packer -debug flag (totally forgot).

Sadly, the -debug flag only yield several additional blank lines and nothing else. I'll create an issue over on the packer github project with a back reference to this one.

[dylanmei]

I've steered away from the puppet-masterless provisioner because of mitchellh/packer#1007. Using a combo puppet-masterless and shell-provisioner is awkward indeed!

[kensykora]

I've run into this issue as well and have completely abandoned trying to get packer to run the puppet provisioner on Windows. Vagrant does a much better job of handling it. I think some if it may have to do with the frustrating issues with ssh and cygwin so that might possibly be a resolution but otherwise to workaround this I would recommend running puppet from a shell provisioner

[dylanmei]

This works for me. Maybe there's something here for you as well.

in template.json, simplified

  ...
  "provisioners": [{
      "type": "file",
      "source": "./puppet",
      "destination": "C:/Windows/Temp/puppet"
    }, {
      "type": "file",
      "source": "./scripts/site.yaml",
      "destination": "C:/Windows/Temp/site.yaml"
    }, {
      "type": "file",
      "source": "./scripts/site.pp",
      "destination": "C:/Windows/Temp/site.pp"
    }, {
      "type": "shell",
      "remote_path": "/tmp/script.ps1",
      "execute_command": "{{.Vars}} cmd /c powershell C:/Windows/Temp/script.ps1",
      "scripts": [
        "./scripts/puppet.ps1",
        "./scripts/reboot.ps1"]
  }]
  ...

and in puppet.ps1

puppet apply --verbose --modulepath='C:/Windows/Temp/puppet/modules' --hiera_config='C:/Windows/Temp/site.yaml' --detailed-exitcodes C:/Windows/Temp/site.pp

[kensykora]

Closing, please reopen if more information is needed.

[sulaweyo]

I see how this workaround can be applied but i fail to see how an awkward workaround can close this issue. The functionality is not there and even if you can do the same via a workaround the bug still exists. I mean there is a provisioner that is not working for windows.

[petemounce]

Seems like packer has an open tracking bug hashicorp/packer#2566.