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

Improve access to "master" settings

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Normal
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: PUP 5.0.0
    • Component/s: Docs, Language
    • Labels:
      None
    • Template:
    • Team:
      Puppet Developer Experience
    • Story Points:
      1
    • Sprint:
      PDE 2017-05-31
    • Release Notes:
      New Feature
    • Release Notes Summary:
      Hide
      All individual variables in the {{$settings}} namespace are now available as a Hash of <setting-name> => <setting-value> in the variable {{$settings::all_local}}. This makes it easy to lookup a setting that may be missing when {{\--strict_variables}} is in effect.
      Show
      All individual variables in the {{$settings}} namespace are now available as a Hash of <setting-name> => <setting-value> in the variable {{$settings::all_local}}. This makes it easy to lookup a setting that may be missing when {{\--strict_variables}} is in effect.
    • QA Risk Assessment:
      No Action

      Description

      Currently, there is a namespace settings in which all settings are set as individual variables. This makes them harder to use as the available settings change between versions, and using strict variables can cause errors, and the available settings cannot be enumerated. Having a $settings as a hash of all settings is desirable, and is analog to how $facts work.

      Note that PUP-1581 is about making possible to also access the settings from a node. That complicates this ticket with having to take future agent settings into account when designing how the improved access should be done. The settings for the compiling runtime (in master mode, or when doing a puppet apply) is what is currently reflected in settings. When designing the support for $settings, is that a good name for the variable? What should the variable for the "node settings" be? Should we use "local" and "node" as subkeys - that is $settings[local] is what we have now, and $settings[node] what will be added in PUP-1581, or should we have two global variables? We could also keep the existing namespace, so that $settings::local and $settings::node (or the asymmetrical $settings and $settings::node).

      If we use the existing namespace, support for this can be added in 4.x. If we go for that option, the two sections "local" and "node" will need to coexist with all the existing settings, and thus those names cannot be used as new settings (they are not used now).

      Another alternative is to add a function settings(name) which would return a setting or an Iterable over all settings if not given a name. This would reduce the amount of data kept in memory (there are many settings, and only a few of them, if any) are ever used in manifests. The return of an iterable means that the settings can be efficiently iterated (without first having to create a hash copy).

      We could also bind the Iterable to $settings, as that would be the most efficient, as the result is almost indistinguishable from a Hash.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              Unassigned
              Reporter:
              henrik.lindberg Henrik Lindberg
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:

                  Zendesk Support