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

Backwards incompatible fact type changes

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Normal
    • Resolution: Done
    • Affects Version/s: FACT 2.3.0, FACT 2.4.3
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Template:

      Description

      This is more of a policy question (I suppose) than anything. The change introduced in FACT-695 (facter 2.3.0) is (potentially) a backwards-incompatible change with respect with to custom facts that confine against any of those facts whose type was changed.

      This is contrary to the release notes for Facter 2.3.0 which state that "Facter 2.3.0 is a backward-compatible feature release in the Facter 2 series."

      In my specific case, I have custom facts which confine against is_virtual being the string true (which was the behavior of that fact's value previous to 2.3.0). The data type change breaks my custom fact because now that value is the boolean true.

      So I'm wondering about the motivation behind these types of changes and their impacts. I think that interacting with the value of a fact (which I think includes its data type) is clearly a part of Facter's "public" API, and thus any change to that value means a backwards incompatible release. Although it seems simple in principal to simply update my custom fact to use the new type, there are downstream repercussions – other custom Facter code, Puppet modules utilizing fact values/types, Puppet RSpec tests with stubbed fact values. These aren't difficult so much as tedious to update, but it is somewhat annoying

      I'm not sure what the QA solution to this issue is, since all of the RSpec tests in that commit were also updated to reflect the type change. But it would be useful if some sort of guarantee could be made about the values being returned by Facter since users depend on those values in their Facter/Puppet code.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                Unassigned
                Reporter:
                jcmcken Jon McKenzie
              • Votes:
                0 Vote for this issue
                Watchers:
                4 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Zendesk Support