Uploaded image for project: 'PuppetDB'
  1. PuppetDB
  2. PDB-3318

Default node-ttl to 7, node-purge-ttl to 14

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Normal
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: PDB 5.0.0
    • Component/s: None
    • Labels:
    • Template:
    • Team:
      Systems Engineering
    • Story Points:
      2
    • Sprint:
      PuppetDB 2017-05-03
    • Release Notes:
      New Feature
    • Release Notes Summary:
      Hide
      PuppetDB now ships with better defaults for node-purge-ttl and node-ttl. node-purge-ttl now defaults to 14 days if left unconfigured, so that old unused information is automatically flushed from the database. node-ttl defaults to 7 days, auto-expiring nodes which haven't checked in in a week. PE already had this defualt; this change applies the same value to the open source release.

      To retain the old behavior, set node-ttl and node-purge-ttl to "0s" in your PuppetDB configuration file.
      Show
      PuppetDB now ships with better defaults for node-purge-ttl and node-ttl. node-purge-ttl now defaults to 14 days if left unconfigured, so that old unused information is automatically flushed from the database. node-ttl defaults to 7 days, auto-expiring nodes which haven't checked in in a week. PE already had this defualt; this change applies the same value to the open source release. To retain the old behavior, set node-ttl and node-purge-ttl to "0s" in your PuppetDB configuration file.
    • QA Risk Assessment:
      Needs Assessment

      Description

      The problem

      When you create and destroy nodes in your puppet infrastructure you build up a lot of deactivated nodes in your PuppetDB database that serve no real purpose but do slow down the performance of the database and cause it to grow.

      Suggested Solution

      node-purge-ttl should be enabled by default and set equal to or higher than report-ttl. It should generally be set to an interval longer than report-ttl to avoid needing the node purge process to also delete reports.

      Considerations

      It could be that we need to add a migration step that will delete old nodes during an upgrade so that post-upgrade the service isn't churning through deleting nodes but not processing catalogs or facts.

      Upon further thought, it would probably be better to implement PDB-3173 and have the default be that node-purge-ttl will only delete up to 100 nodes whenever it runs. Then when this setting is enabled it shouldn't suddenly cause too much churn if you have 1000s of deactivated nodes.

        Attachments

          Issue Links

            Activity

              jsd-sla-details-panel

                People

                • Assignee:
                  russell.mull Russell Mull
                  Reporter:
                  nick.walker Nick Walker
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  3 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: