Uploaded image for project: 'Facter'
  1. Facter
  2. FACT-1873

Custom facts that aren't suitable should not override built-in facts

    Details

    • Template:
    • Team:
      Platform OS
    • Sprint:
      Platform OS Kanban
    • Release Notes:
      Bug Fix
    • Release Notes Summary:
      Hide
      Custom facts conflicting with built-in facts properly fall-back to the built-in value if no custom facts resolve while also ensuring that built-in facts have precedence over 0-weight custom facts.

      Release note draft:

      Prior to this release, Facter overrode built-in facts with custom fact values, even if the custom fact had no valid implementation. Now if custom facts return an empty result in conflict with built-in facts, Facter ignores that value and returns the built-in fact value. with built-in facts, but do not resolve, the built-in value is returned.
      Show
      Custom facts conflicting with built-in facts properly fall-back to the built-in value if no custom facts resolve while also ensuring that built-in facts have precedence over 0-weight custom facts. Release note draft: Prior to this release, Facter overrode built-in facts with custom fact values, even if the custom fact had no valid implementation. Now if custom facts return an empty result in conflict with built-in facts, Facter ignores that value and returns the built-in fact value. with built-in facts, but do not resolve, the built-in value is returned.
    • QA Risk Assessment:
      Needs Assessment

      Description

      As a user of Facter, I would expect that a custom fact, with weight > 0, and with confines which have it result in being not suitable for the current system should not replace the built-in fact with an empty result.

      Or, put more generally, I would expect facter to pick the highest weighted fact available from the set of facts where the confines return success.

      Example with a fact in myfacts/custom.rb:

      Facter.add(:timezone) do
        has_weight 10
        confine { File.exist?('/tmp/fact_trigger') }
        setcode do
          'my_custom_timezone'
        end
      end

      and:

      $ facter timezone
      UTC

      then, as expected:

      $ touch /tmp/fact_trigger
      $ facter --custom-dir=myfacts timezone
      my_custom_timezone

      after removing /tmp/fact_trigger, causing the confine to fail:

      $ rm /tmp/fact_trigger
      $ facter --custom-dir=myfacts timezone
       
      $
      

      what I would have expected to happen is:

      $ rm /tmp/fact_trigger
      $ facter --custom-dir=myfacts timezone
      UTC
      $
      

       

      The behavior as it is today prevents targeted fixing of particular facts on specific platforms that don't work as well as on other platforms by narrowing down the scope with confines.

      Thank you.

       

        Attachments

          Activity

            jsd-sla-details-panel

              People

              • Assignee:
                enis.inan Enis Inan
                Reporter:
                seanmil Sean Millichamp
              • Votes:
                2 Vote for this issue
                Watchers:
                7 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: