- It can be difficult to determine when an agent upgrade has actually
   completed on Windows, because a sequence of events must occur:

   * the current puppet run must complete, preventing file locking
   * the install_puppet.bat script waits 5 seconds, then infinite
     loops until a given PID is no longer running (from prior run)
   * the actual MSI must run to completion (it may encounter issues if
     for some reason any Puppet services / processes are still running)

   This can make it very difficult to implement a deterministic
   behavior around waiting until an upgrade completes in an effort to
   synchronize / orchestrate additional actions post-upgrade.  This
   is of particular importance to tests that may eagerly perform
   validations on the upgrade prior to the upgrade actually finishing.

 - Improve the process by writing a %TEMP%\puppet_agent_upgrade.pid
   file during the upgrade that is cleared after an upgrade completes.
   Other external parties may use the existence of this file as an
   indicator that an upgrade is underway.

 - As part of the 1.2 release, the scope of upgrades was changed to include 3.7.  Makes sure that
   metadata.json reflects this.

…e-upgrade-Windows-PID-file

(MODULES-3433) Write Windows PID file on upgrade

(maint) Update metadata.json for Puppet 3.7

 - Previously, upgrades could fail as a result of the pxp-agent service
   holding file locks.  While we have been previously aware of the
   potential for this issue, given pxp-agent runs under nssm.exe on
   Windows, prior investigation had shown this to not be an issue on
   silent installations (see PA-65).

   However, in practice, while upgrading from puppet-agent 1.4.2 to
   puppet-agent 1.5.0, a running pxp-agent service is preventing
   installs from proceeding as requested with a 1603 failure. NSSM.exe
   is not affiliated with the pxp-agent service in the MSI and therefore
   the Restart Manager has no understanding that it will be later
   shutdown and unlocked.

   The solution is to simply request a `net stop pxp-agent` prior to
   running the MSI.  It's very important that this be done *after* the
   puppet run responsible for triggering the upgrade has been performed.
   If the pxp-agent service shutdown occurs before, then the puppet run
   will typically turn it back on as part of managing the node with the
   Puppet Enterprise modules.

 - Specifying the `x` for logging includes extra debugging information
   that can be useful when installations fail.  For instance, it will
   produce more verbose information from the Restart Manager.

…down-pxp-agent-service-on-Windows-upgrades

(MODULES-3449) Stop Windows pxp-agent service

This commit disables client SSL verification on Xenial. We had to
do this in order to work around an issue where client ssl seems to
not be compatible with the SSL certs that PE uses. The root cause of
this change, and why it only occurs in Xenial, is unknown at this time.

(PE-16317) Disable client SSL verification on Xenial

Excludes a lint check we can't satisfy, and fixes up line length to
match 140 character limit. Also locks some dependencies that were
resolving to versions that don't work with Puppet 3.8 or Ruby 1.8.

(maint) Fix up tests

We have to shell out to puppet config print to preserve environment
config. This gives us how the agent is configured, not how the enc or --environment
override is set, this 100% ensures that the msi installer when it writes
the environment configuration value is how the agent was configure
pre-upgrade.

(MODULES-3517) Explicitly setting environment to nodes current environment

Allow setting the INSTALLDIR option for the Windows MSI.

Added a test for the consequence of stringify_facts = true in agent puppet.conf.

(MODULES-3571) Allow setting install_path for MSI

 - The previous checks for PID running uses a combination of tasklist,
   findstr and some more cryptic batch-isms to detect if a puppet
   agent is currently executing (by PID).  This check also relies on
   the English string "No tasks are running", because tasklist.exe
   doesn't set exitcodes as desired when the query is not a match.

   C:\Users\Administrator>tasklist.exe /FI "PID eq 1234" /NH
   INFO: No tasks are running which match the specified criteria.

   C:\Users\Administrator>echo %ERRORLEVEL%
   0

   There are a couple of alternative methods for achieving the
   desired functionality.  The simplest is qprocess.exe:

   C:\Users\Administrator>qprocess 1234
   No Process exists for 1234
   C:\Users\Administrator>echo %ERRORLEVEL%
   1

   C:\Users\Administrator>qprocess 32936
   USERNAME              SESSIONNAME         ID    PID  IMAGE
   >administrator         console              1  32936  mmc.exe
   C:\Users\Administrator>echo %ERRORLEVEL%
   0

   Unfortunately qprocess is no longer available on Nano Server, so
   the next best option is wmic.exe, which exists everywhere.

   C:\>wmic PATH Win32_Process where handle=1111 get handle /format:textvaluelist |
     findstr /I "Handle=1111"
   No Instance(s) Available.

   C:\>echo %ERRORLEVEL%
   1

   The string 'Handle' appears everywhere, so no locale specific
   string parsing is required on non-English versions of Windows, such
   as German:

   C:\Users\moses>tasklist /FI "PID eq 1234" /NH
   INFORMATION: Es werden keine Aufgaben mit den angegebenen Kriterien ausgeführt.

   C:\Users\moses>echo %ERRORLEVEL%
   0

 - Previously, the batch file would wait for an infinite amount of
   time for the calling Puppet process to exit, before it would
   proceed with an upgrade.

   Prior to rewriting the PID check with wmic, this could cause an
   infinite loop when trying to match an unlocalized string.

   Since infinite loops are never a good idea, cap the wait limit to
   120 seconds, and log an event log message under Puppet / ID 101
   that the agent upgrade failed.

   This should improve the end user experience under failing
   circumstances.

Previously the script was using the timeout.exe application however this
attempts to redirect STDIN and during a headless operation, for example during
an actual puppet run, this throws an error and does not wait the proper time.
This commit changes the wait method to use ping.  Ping waits 1 second between
attempts therefore a simple `ping 127.0.0.1 -n 6` will pause for 5 seconds.

This commit also changes the location of the PID file slightly.  Previously it
used `%TEMP%` however this variable can be removed or be in an unexpected place.
Instead the PID file is always placed in the same directory as the
script (`%~dp0`).

To assist in debugging upgrade failures the install batch file also outputs
all environment variables prior to running.

…-for-pid-properly-on-non-English-Windows

(MODULES-3636) Upgrade on non-English Windows

…ot-wait-indefinitely-on-agent-PID

(MODULES-3434) Wait 120 seconds for Windows agent

(MODULES-3657) Fix waiting on Windows during upgrade

Prior to this commit we were managing the puppet symlink, even
though that symlink is also managed by PE and most likely a
user would manage it themselves if they wanted it.
This commit removes management of the symlink, since it conflicts
with PE and is generally inconsistent with the rest of the OSes
managed by this module.

Our CI setup puts extra files in the project workspace, which
puppet-lint then tries to lint. This fails for older versions of Puppet.

Fix up SSL configuration for use with fixes in stomp 1.4.1.
Without this the activemq-stomp connection will reject the connection.

(PE-17012) Do not manage puppet symlink

(maint) Add puppet-lint workarounds for CI, use valid certnames

(maint) Fixes typo in Rakefile

(maint) Fix CI, where host['ip'] is nil

puppet-lint added checking variable case on a bug fix release. Address
the noted issues.

(maint) Fix linting

Set perms for Windows package differently than for Linux

…all-the-things

(RE-7976) Update to use the new GPG key

configuration of PE/FOSS repositories

This is intended to enable users to utilize existing systems management
tools and internally hosted repositories to ensure agent upgrades

This commit modifies the install logic when `osfamily` is `RedHat`
to accommodate for the `fedoraf` package suffix when the OS is
fedora rather than an `el` derivative.

Prior to this commit the `puppet-agent` package would be suffixed
with `el` which does not match the package naming convention for
fedora.

…suffix

(PE-17508) Fix puppet-agent suffix on fedora

…ncasing as the current code on Suse simply converts all letters to the character 'a' and causes each run to re-import keys

Note that log locations that have been explicitly configured are not
reset when upgrading from Puppet 3.

Closes #157.

Puppet 4 warns about unknown variables, as in
```
Warning: Unknown variable: '::platform_tag'. at
/root/puppet/modules/puppet_agent/manifests/params.pp:75:17
Warning: Unknown variable: '_package_version'. at
/root/puppet/modules/puppet_agent/manifests/init.pp:108:8
```

Fix by avoiding unknown variables, or guarding variables we know aren't
defined. Fixes #156.

updated unless condition on Suse/Redhat GPG key imports to ensure downcasing

(docs) Note unchanged config options

(MODULES-3896) Avoid unknown variables

Prior to this commit, puppet-agent upgrades on AIX were constrained to
POWER 5-7 architectures.

However, if Puppet is already running on a supported version of AIX, it
should be safe to assume we're on a supported POWER version.

This commit removes the POWER version constraint, allowing upgrade on
POWER8 and higher architectures.

This commit updates the logic for cleaning a vanagon package version
name to be compatible with the IPS requirements for solaris ll p5p
package naming. It adds the same logic found in vanagon itself for
removing any leading zeros from the dotted segments of the version
string.

Prior to this commit, leading zeros in a version segment were left
in the package name which violates p5p naming rules. This caused
vanagon builds containing such a version to fail the install
process.

Ref:
[vanagon ips version code](https://github.com/puppetlabs/vanagon/blob/master/lib/vanagon/platform/solaris_11.rb#L94-L107)
[Solaris 11 package versioning](http://www.oracle.com/technetwork/articles/servers-storage-admin/ips-package-versioning-2232906.html)