Uploaded image for project: 'Puppet'
  1. Puppet
  2. PUP-1763

Puppet run continues despite failed Pluginsync

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Normal
    • Resolution: Fixed
    • Affects Version/s: PUP 3.4.3
    • Fix Version/s: PUP 5.5.22, PUP 6.18.0
    • Component/s: None
    • Labels:
    • Environment:

      RHEL6

    • Template:
      PUP Bug Template
    • Team:
      Coremunity
    • Sprint:
      Platform Core KANBAN
    • Release Notes:
      Bug Fix
    • Release Notes Summary:
      Hide
      Previously, puppet agents ignored pluginsync errors and would apply the catalog with possibly incorrect facts and plugin versions, leading to obscure errors or data corruption. This release adds a new setting `ignore_plugin_errors`. If set to false, then the agent will abort the run if pluginsync fails. The setting defaults to true so the old behavior is preserved. In Puppet 7, the default value will be switched to false.
      Show
      Previously, puppet agents ignored pluginsync errors and would apply the catalog with possibly incorrect facts and plugin versions, leading to obscure errors or data corruption. This release adds a new setting `ignore_plugin_errors`. If set to false, then the agent will abort the run if pluginsync fails. The setting defaults to true so the old behavior is preserved. In Puppet 7, the default value will be switched to false.

      Description

      A puppet run that has enough custom types/providers/facts to sync to a local system that it exceeds configtimeout (default 2m), should not continue to perform a puppet run, but rather completely fail. This would be the only way to meet the expectation that pluginsync ensures certain types/providers/facts are available before a module's code runs.

      If a puppetrun can continue despite failing to download plugins or custom facts, the proper operation of puppet modules cannot be guaranteed (without sanity checks in the puppet code). Also, it becomes impossible to base a Hiera hierarchy off of a custom fact because the first run would fail to pull in the expected Hiera data.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              josh Josh Cooper
              Reporter:
              wvl0 William Leese
              Votes:
              4 Vote for this issue
              Watchers:
              7 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:

                  Zendesk Support