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

Overriding evaluated resources silently changes its parameters wo re-eval

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Normal
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: PUP 5.1.0
    • Component/s: Compiler, Language
    • Labels:
      None
    • Template:
    • Acceptance Criteria:
      Hide

      That if a user defined resource has been evaluated and is overridden that one of the following actions are being taken by puppet:

      • --strict=off: Silently skip, parameters overridden are changed (current 4.6.2 behaviour)
      • --strict=warning: Warn on each evaluated resource and skip (and current 4.6.2 behaviour)
      • --strict=error: Error on override of evaluated resource, fail compilation.
      Show
      That if a user defined resource has been evaluated and is overridden that one of the following actions are being taken by puppet: --strict=off : Silently skip, parameters overridden are changed (current 4.6.2 behaviour) --strict=warning : Warn on each evaluated resource and skip (and current 4.6.2 behaviour) --strict=error : Error on override of evaluated resource, fail compilation.
    • Epic Link:
    • Sub-team:
    • Team:
      Agent
    • Story Points:
      2
    • Sprint:
      Agent 2017-06-28, Agent 2017-07-12
    • Release Notes:
      Bug Fix
    • Release Notes Summary:
      Hide
      Overriding attributes of user defined resources after the resources have been evaluated leads to an inconsistent catalog in that the parameters shown are not the actual values used to produce the content of the resource.
      Now, the {{\--strict}} flag will help find and correct these issues in manifests. A setting of {{{\--strict=off}} will continue to behave as it does now, a {{\--strict=warning}} will issue a warning for each override, and {{\--strict=error}} will fail the compilation.
      It is expected that a future version of puppet will always fail the compilation in this situation.
      Show
      Overriding attributes of user defined resources after the resources have been evaluated leads to an inconsistent catalog in that the parameters shown are not the actual values used to produce the content of the resource. Now, the {{\--strict}} flag will help find and correct these issues in manifests. A setting of {{{\--strict=off}} will continue to behave as it does now, a {{\--strict=warning}} will issue a warning for each override, and {{\--strict=error}} will fail the compilation. It is expected that a future version of puppet will always fail the compilation in this situation.
    • QA Risk Assessment:
      Manual

      Description

      Override of user defined resources that have been evaluated will just change its parameters without re-evaluating its body. It also says nothing about that this happened. This is a problem in itself since it means that the resource will end up in the catalog with different parameters than those that were used when its body was evaluated. It is like having evaluated "add(2,2)=>4" and then changing it so it is reported as "add(3,2)=>4". This is total nonsense.

      define foo($message) { notify {"$title n1": message => $message } }
      notify { 'n1': message => 'unchanged' }
      foo {'f1': message => 'unchanged' }
      define delayed {
        Notify <| title == 'n1' |>    { message => 'changed' }
        Foo    <| title == 'f1' |>    { message => 'changed' }
      }
      delayed {'d1': }
      

      Produces:

      Notice: Compiled catalog for funnybones.com in environment production in 0.06 seconds
      Notice: changed
      Notice: /Stage[main]/Main/Notify[n1]/message: defined 'message' as 'changed'
      Notice: unchanged
      Notice: /Stage[main]/Main/Foo[f1]/Notify[f1 n1]/message: defined 'message' as 'unchanged'
      

      In the example above it can be noted that the notify resource in the 'foo' body is unchanged since the parameters to Foo[f1] was changed after evaluation.

      This means that override is sensitive to evaluation order. We cannot perform reevaluation of the resource as it ultimately leads to the ability to write infinite loops (the change causes it to do another override, it could then also be used to affect the logic that included it in the first place which in essence means user has access to the catalog and can mutate anything (although with a horrible blunt API).

      It should probably be an error to override something that has already been evaluated as the result that is produced is nonsense. Such a change is however not backwards compatible since currently nothing much happens and the change would break manifests that do this.

      The more drastic approach of removing overrides will not work as long as what it is used to solve is not supported in a better way (e.g. merging reources).

        Attachments

          Activity

            People

            Assignee:
            john.duarte John Duarte
            Reporter:
            henrik.lindberg Henrik Lindberg
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved:

                Zendesk Support