Generate Packer JSON Files #3
Comments
|
The hooks are a good idea. I have really minimal requirements, I just want to install: OS, OS patches, Chef, VMWare or VBox tools. In fact I'd rather not install Cygwin if I could. |
|
Cygwin is a silly requirement because @mitchellh decided to write Packer in Go ;) Or said another way: Go has no WinRM library, because it has no WS-* library, because it has no SOAP library, because the Go community hates SOAP / has no interest in implementing anything with it (See: https://botbot.me/freenode/go-nuts/msg/4943492/, https://botbot.me/freenode/go-nuts/msg/4943637/, https://botbot.me/freenode/go-nuts/msg/4943655/, https://botbot.me/freenode/go-nuts/msg/4943756/ & actual civility here: https://botbot.me/freenode/go-nuts/msg/4943739/). For the record, I understand their frustration with SOAP and WS-*, but the attitude is unbecoming, but is typical of the community's attitude towards Windows. Such is life. I believe @mitchellh is thinking of shelling out to a ruby-based helper to provide WinRM support in the future in a way that is consistent for both Packer and Vagrant. Essentially we install Cygwin purely to allow Packer to say 'hello, world!' to know it can move on to run the shutdown command. We could register a script in the registry to ensure that on first boot, it's removed again. But if we want people to be able to work with Packer provisioners, Cygwin is essential. |
|
Windows 2012 R2 is available now as a download from MSDN. It's quite likely that I will switch to it within weeks. Joe, can I assume you want to drive the build with trollop and command-line options? We could also use WinRM to remove Cygwin at end of the build after packer has done its thing. |
|
That makes sense - Trollop or some equivalent would be fine, and we could use a Ruby templating engine to build the .json file. I'm interested in moving to 2012 R2 also. Hopefully it'll drastically cut down the time to build the box due to a lack of Windows Updates to apply ;) If we use WinRM to remove Cygwin at the end of the build it could get a little complex, as packer's final 'action' prior to packaging is to run the shutdown command, which requires SSH. Seems like an easier option would be to just throw a script in HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Run so that Cygwin is removed on first boot of the box. |
|
Ah now I'm following. If we have some canned scripts that others can mix-and-match, then it makes sense to provide one to help remove Cygwin on first boot. (Also, enable remote desktop, disable hibernation, etc...) Otherwise you what, create a vagrant-windows post-processor? :/ |
|
... Or you wait for @mitchellh to create a Ruby helper that Packer calls to leverage WinRM, allowing us to avoid installing Cygwin in the first place. |
|
Work on this will continue at https://github.com/joefitzgerald/inductor |
|
Fixed by #200 |
Switch back to en-US and PST
…ider-v-17692 Update 2019 insider iso to 17692
Picking up the conversation where we left off in Dylan's pull request: #1 .
I think there are a few dimensions that are required for a minimally useful packer-windows template:
If we could provide some level of reuse at each level (OS Version, OS Edition, Builder, Provisioner), that would hopefully drastically reduce the number of distinct .json files we manage (because we can generate them).
I agree with Shawn that we need to maintain the ability to customize, which could be achieved via the build process, or by providing hooks for extensibility (e.g. if user defined script x exists, run it after the core provisioning steps). Also, there's nothing stopping someone from taking a .json file we generate and then customizing it from there.
Does that make sense? Do you think I'm missing any obvious requirements?
The text was updated successfully, but these errors were encountered: