Puppet

Pieter,

I ran into a couple of issues during the implementation of the PMT update command:

• When upgrading modules with the command ‘puppet module update foo’, should we updated all versions of foo installed in all directories found in the module path?

yes

• When upgrading modules with the command ‘puppet module update foo’, should we updated all modules with a subdirectory name ‘foo’ but no metadata under the modulepath?

No, we don’t do stuff with modules that don’t have metadata, but we should warn the user of what happened.

• Module path ‘A’ could have foo install but the ‘forge name’ is puppetlabs-foo, Module path ‘B’ could have foo installed but the ‘forge name’ is kelseyhightower-foo.

  • Which one do we upgrade?

  • Which one do we request from the forge? kelseyhightower-foo or puppetlabs-foo? Currently you cannot request just request ‘foo’ from the forge.

    The upgrade command (and others) takes author-name (fully qualified), so this shouldn’t be an issue

• When upgrading modules with the command ‘puppet module update foo’, should we install something even if nothing was there before? Can we upgrade something that is not installed?

No, error and tell them how they would run install

Here’s further clarification of upgrade. We should be able to reuse most of the install code, maybe just need to pass a few extra options to deal with —force behaving slightly differently between the two commands.

`puppet module upgrade`

The Story: "Upgrade lets me change the version of a module, without breaking the system."

Module not installed
  => Installed as if not installed
Module is installed
  Specified version installed
    No `--force` flag
      => Upgrade fails
    Provided `--force` flag
      => Upgraded as if older version
  Different version installed
    Installed module has no local changes
      Module has no dependencies
        => Installed module is overwritten by new module
      Module has dependencies
        Dependencies not installed
          => Installed module is overwritten by new module
          => All dependencies are installed alongside the module (same part of modulepath)
        Some dependencies installed (meeting requirements)
          => Installed module is overwritten by new module
          => Uninstalled dependencies are installed alongside the module
        Some dependencies installed (not meeting requirements)
          Dependency requirements overlap
            => Installed module is overwritten by new module
            => Uninstalled dependencies are installed alongside the module
            => Installed dependencies get upgraded
          Dependency requirements do not overlap
            => Upgrade fails
    Installed module has local changes
      No `--force` flag
        => Upgrade fails
      Provided `--force` flag
        => Upgraded as if no local changes

Other Nodes:

* Default version is `latest` / `best`.