Conflicts:
	lib/puppet/feature/base.rb
	lib/puppet/file_serving/configuration.rb
	spec/unit/indirector/ssl_file_spec.rb
	spec/unit/parser/functions/extlookup_spec.rb
	spec/unit/resource/catalog_spec.rb
	test/language/ast/variable.rb

Added missing spec tests for Windows service provider methods:
  :stop, :enable, :disable, and :manual_start
Refactored to match Nick's previous work.

Reviewed By: Nick Lewis [nick@puppetlabs.com]
(cherry picked from commit d08ae7fd2180c95d1fcafa149128d25cc4680c6c)

This provider, windows_adsi, uses the Puppet::Util::ADSI module to manage
groups. It can only manage group existence and memberships, but is fully
functional in those regards.

Based on work by: Joel Rosario <joel.r@.internal.directi.com>
Based on work by: Cameron Thomas <cameron@puppetlabs.com>
Reviewed-By: Matt Robinson <matt@puppetlabs.com>
(cherry picked from commit 01f09f5f395bab66b90a4e81e958aa89025977b4)

This provider, windows_adsi, uses the Puppet::Util::ADSI module to manage
users. It can currently only manage group memberships, comments, and home
directories, which are the only fields that can be managed via ADSI.

Based on work by: Joel Rosario <joel.r@.internal.directi.com>
Based on work by: Cameron Thomas <cameron@puppetlabs.com>
Reviewed-By: Matt Robinson <matt@puppetlabs.com>
(cherry picked from commit ac00e9e289f8fdc81f060e7dd289e1a8e0f133c0)

The host provider did not work on Windows because it didn't know where
to find its hosts file. The provider now uses Win32::Resolv, which is
part of the standard ruby library, to find it.

Several host type/provider spec tests were marked as fails_on_windows,
but now that the provider is working, I removed the tag from those
tests, and verified that the tests now pass. There are two tests in
resources_spec that fail because the user and exec providers are not
supported on Windows yet, so those tests are marked as fails_on_windows.

Reviewed-by: Pieter van de Bruggen <pieter@puppetlabs.com>
(cherry picked from commit 82c6b3cb41397c989c011cf767066bcf1e403db2)

Because Windows allows a service to be both running and disabled, we now
support that capability. If a service is explicitly requested to be running and
disabled, we will set it to manual start if necessary, start it, and then
disable it. If the service is requested to be running and enabled, we will now
enable it before attempting to start it (previously, this would simply try to
start it and fail).

The exception to this rule is a service which is disabled, and for which we are
not managing the enable property. In that case, we assume that some other
authority has disabled the service, and respect that, failing to start. Thus,
if the user actually wants a service to be running and disabled, they must
explicitly declare that intent.

Reviewed-By: Jacob Helwig <jacob@puppetlabs.com>
(cherry picked from commit 12d0018f93e5a72a728c6decffb351a693a86344)

Because the enable property of the service type uses :true and :false as its
valid values, rather than true and false, we need to return :true and :false
from our enabled? method. Otherwise, the property was being synced every time
it was enabled or disabled, regardless of whether it was actually in sync or
not.

Reviewed-By: Jacob Helwig <jacob@puppetlabs.com>
(cherry picked from commit 44e2d494f499e2005c1b31b92b97834189d4224d)

We want to use self.debug for logging in the provider, so that log messages are
properly associated with the resource, rather than generically coming from
Puppet.

Also fix the self.instances method to not use an unnecessary extra variable
when collecting.

Reviewed-By: Jacob Helwig <jacob@puppetlabs.com>
(cherry picked from commit 38c181d00e87ecc699c6a3e23dd2155f716a6602)

This provider allows us to query the system state through "puppet
resource", and manage the ensure, and enabled properties of services on
Windows.

This also adds support for a new enabled value of 'manual' on Windows
only.  With this we support the three major start types for services on
Windows, with the following mapping of enabled to start type:

  true   => Automatic
  false  => Disabled
  manual => Manual (Demand)

We use the win32-service gem to provide access to the Windows APIs for
our operations.  This does add a new gem requirement for running Puppet
on Windows, but we were already requiring some gems from the same suite
that win32-service is a part of.

When referring to a service, the simple service name must be used,
instead of the display name.  For example, "snmptrap", instead of
"SNMP Trap".

All system services are reported in 'puppet resource service',
including those started prior to run level 3 (system, device drivers,
etc.).  These services should probably not be managed, without careful
thought and planning.

This currently does not support being able to move a service from
{enabled => false, ensure => stopped} to {enabled => true, ensure =>
running} (or enabled => manual) in a single Puppet run, since Puppet
currently always tries to sync ensure before any other property.
Because of this, the puppet run will fail every time, and the service
must first be managed as {ensure => stopped, enabled => true} (or
enabled => manual), before it can be managed as running and automatic
start or manual start.

Reviewed by: Jacob Helwig <jacob@puppetlabs.com>
(cherry picked from commit 82476e8be41b62ce1767ab6854a72b481b917380)