Chef/ChefClient provisioner fixes, Linux/OS X host OS fixes #6
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Updated so that the configurable timeout value is honored on the WinRM call
…t error, Hack WinRb#4 by calling net use to "warm-up" virtual box"
…) and distro_dispatch (which is stubbed) ... Bumped version to reflect local changes. Converted distro_dispatch to use the WMI method. Converted renames to use an explicit cmd executor. Added a convenience function for running WMI queries and retrieving the responses. Force backslashes in uploaded files on target. New monkey patches for Chef and ChefClient provisioners. These use Windows-specific behavior (concerning paths and upload behavior) if you specify a :windows guest.
…e Windows2008R2 / Windows2003 classes inherit from it... This is hopefully enough work to allow future contributors to customize Vagrant's guest behavior for other Windows versions. Bumped version.
… to work, FIXME ... ) Modified config.provisioning_path to always point to C:\chef or /etc/chef depending on platform. Version bump to 0.1.2. Trimming out cyan-colored 'winrm' prefix on output as it's really messing with my log warning parser thing, man.
…log level in client.rb to :debug. It's back to :warn, which is Vagrant's default behavior. Please note that passing in your own debug level doesn't seem to work right now. (Sorry.)
| @@ -118,16 +117,19 @@ def h | |||
| @highline ||= HighLine.new | |||
| end | |||
|
|
|||
| # this breaks a Jenkins plugin that scans for log events, so we're nerfing it. | |||
| def print_data(data, color = :cyan) | |||
There was a problem hiding this comment.
We should kill the color options.
There was a problem hiding this comment.
The color options were inherited from upstream, but I can't remember whether it was from vagrant-windows or vagrant itself.
Either way, I totally agree with you. :D
|
@leftathome We have since moved on and made the decision not to support windows 2003 and have fixed various bugs that this pull request addresses. Thanks much for your time and energy, it has helped us fix a number of bugs with a scalpel. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
My organization had a need to spawn Windows 2008 VMs on Linux and OS X guests and provision them against a Chef server. I extended vagrant-windows to provide this functionality. It's not perfect but I'm sure the added functionality will be useful for someone.
The distro-finding dispatch logic should also now work, so if someone wants/needs to add behavior specific to a particular flavor/vintage of Windows, the groundwork is there.
Unfortunately, none of this work is going to be compatible with Vagrant 1.1 (nor, for that matter, is the vagrant-windows gem), so at some point all of this will have to be converted to 1.1's plugin architecture.
(Maybe someone who really wants all this to work in VMware will take it on?)