Announce: Facter 2.2.0

[Adrien Thebo]

Facter 2.2.0 is a backward-compatible features-and-fixes release in the Facter 2 series. The release adds structured versions of several core fact types and contains backports of facts that were merged into Facter master but were not released in Facter 2.0.1.

Headline features

  - new structured facts: os, system_uptime, processors

To download Facter, follow the instructions here: http://docs.puppetlabs.com/guides/install_puppet/pre_install.html

Release notes are available here: http://docs.puppetlabs.com/facter/latest/release_notes.html

To see a complete list of issues fixed in this release: https://tickets.puppetlabs.com/issues/?filter=12624

We're tracking bugs people find in this release with the "Affected Version" field set to "2.2.0": https://tickets.puppetlabs.com/issues/?filter=12623

--

Adrien Thebo | Puppet Labs

[Matt W]

Hey we got this installed on some new systems yesterday and we found that in Ubuntu 12 the `lsbmajdistrelease` fact has changed suddenly from `12` to `12.04`! This actually broke quite a few of our manifests, and is fundamentally broken I believe. The major dist release version is '12'. Has anyone else seen this?

root@dev-mwise-test-array-9-i-8046108d:~# facter -p | grep lsb
lsbdistcodename => precise
lsbdistdescription => Ubuntu 12.04.3 LTS
lsbdistid => Ubuntu
lsbdistrelease => 12.04
lsbmajdistrelease => 12.04
lsbrelease => core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:core-4.0-amd64:core-4.0-noarch
os => {"release"=>{"full"=>"12.04", "major"=>"12.04"}, "name"=>"Ubuntu", "family"=>"Debian", "lsb"=>{"release"=>"core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:core-4.0-amd64:core-4.0-noarch", "majdistrelease"=>"12.04", "distcodename"=>"precise", "distrelease"=>"12.04", "distdescription"=>"Ubuntu 12.04.3 LTS", "distid"=>"Ubuntu"}}
root@dev-mwise-test-array-9-i-8046108d:~# dpkg --list | grep -i facter
ii  facter                            2.2.0-1puppetlabs1                Ruby module for collecting simple facts about a host operating system
root@dev-mwise-test-array-9-i-8046108d:~#

and after downgrading Facter..

Processing triggers for man-db ...
Setting up facter (2.1.0-1puppetlabs1) ...
root@dev-mwise-test-array-9-i-8046108d:~# facter -p | grep lsb
lsbdistcodename => precise
lsbdistdescription => Ubuntu 12.04.3 LTS
lsbdistid => Ubuntu
lsbdistrelease => 12.04
lsbmajdistrelease => 12
lsbrelease => core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:core-4.0-amd64:core-4.0-noarch 

[Will Hopper]

Hi, Mark!

Thanks for raising your concerns on this. This change was actually intentional, as we have been reporting the Ubuntu major release incorrectly for some time in Facter.

In most platforms, splitting on the first ‘.’ of an X.Y.Z release would be a sane way of determining the major release, but Ubuntu does its versioning a bit differently.

Given the Ubuntu release 10.04, the major version isn't actually 10; it's 10.04 and 10.10 isn't a patch release to 10.04. When Ubuntu does do a minor release for a distribution, they add it as the Z part of the X.Y.Z - for example, 14.04.1 should have a major release of 14.04 and a minor release of 1, not 4.

Thus, our inclination here is to correct the long-standing, incorrect version reporting we’ve historically had for Ubuntu.

A simple, backwards-compatible way to work with this value in your existing manifests would be to use an approximate regex match on the fact value, i.e:  `if $lsbmajdistrelease =~ /^12/ …`

[Will Hopper]

Whoops, apologies, Matt. Not sure where "Mark" came from :).

On Tuesday, August 26, 2014 1:42:56 PM UTC-7, Will Hopper wrote:

Hi, Mark!

[Daniele Sluijters]

Hey,

I agree with the spirit of the fix but the fact that it isn't mentioned anywhere in the release notes is a bit annoying. I personally also consider this a backwards incompatible release, you're changing old behaviour. Albeit for the better, but people depended on that behaviour and no prior warning or deprecation warning was issued.

Do also keep in mind that though we can easily fix our own manifests with a regexp match, since the launch of the Forge people have started to use more and more modules maintained by others. Unless the maintainer has already issued an update you're stuck with manually patching an upstream module and carrying that change. Depending on how you deploy your environment this might be difficult to do.

-- 

Daniele Sluijters

[Konrad Scherer]

On 08/26/2014 04:42 PM, Will Hopper wrote:
> Hi, Mark!
>
>
> Thanks for raising your concerns on this. This change was actually intentional,
> as we have been reporting the Ubuntu major release incorrectly for some time in
> Facter.
>
>
> In most platforms, splitting on the first ‘.’ of an X.Y.Z release would be a
> sane way of determining the major release, but Ubuntu does its versioning a bit
> differently.
>
>
> Given the Ubuntu release 10.04, the major version isn't actually 10; it's 10.04
> and 10.10 isn't a patch release to 10.04. When Ubuntu does do a minor release
> for a distribution, they add it as the Z part of the X.Y.Z - for example,
> 14.04.1 should have a major release of 14.04 and a minor release of 1, not 4.
>
>
> Thus, our inclination here is to correct the long-standing, incorrect version
> reporting we’ve historically had for Ubuntu.
>
>
> A simple, backwards-compatible way to work with this value in your existing
> manifests would be to use an approximate regex match on the fact value, i.e:
> `if $lsbmajdistrelease =~ /^12/ …`

I also agree with the rationale of the fix, but I have lsbmajdistrelease in my
hiera config and this workaround does not work there. A quick grep through my
puppet manifest repo shows several modules like postgres broken by this change
[1]. Some warnings, deprecations, clear release notes and work to make sure
modules are compatible with the change would have made this transition much less
painful for everyone. A "backwards compatible" release shouldn't require so many
code changes to maintain behavior.

[1]:
https://github.com/puppetlabs/puppetlabs-postgresql/blob/master/manifests/params.pp#L121

--
Konrad Scherer, MTS, Linux Products Group, Wind River

[Matt Wise]

+2 here. I support the fix -- but not in a minor-revision of the tool. In our case, it was indeed a reasonably simple regex change everywhere, but the potential for failure around puppet-forge modules is massive here. I strongly recommend reverting this change and releasing it in a 3.xx version of Facter.

Matt Wise

Sr. Systems Architect

Nextdoor.com

--
You received this message because you are subscribed to a topic in the Google Groups "Puppet Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/puppet-users/Ve0L1iW3NeU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to puppet-users+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/53FDD3D6.8020908%40windriver.com.

For more options, visit https://groups.google.com/d/optout.

[Daniel Schaefer]

I've opened a bug here: https://tickets.puppetlabs.com/browse/FACT-686

[Kylo Ginsberg]

On Tue, Aug 26, 2014 at 11:57 PM, Daniele Sluijters <daniele....@gmail.com> wrote:

Hey,

I agree with the spirit of the fix but the fact that it isn't mentioned anywhere in the release notes is a bit annoying.

Yep, it's a release notes fail, and it happened because we didn't track the change with separate tickets. What happened is we made this change as part of adding lsbminordistrelease (FACT-637) and adding the new 'os' structured fact (FACT-614), but it wasn't called out separately. Anyway that's an explanation, but not really an excuse - we dropped the ball on publicizing this change.

We've added tickets for the changes and pushed updated release notes for facter 2.2 here.

 

I personally also consider this a backwards incompatible release, you're changing old behaviour. Albeit for the better, but people depended on that behaviour and no prior warning or deprecation warning was issued.

Although we clearly should have documented this differently, since it's in the wild and there's consensus that this change *is* for the better, we'd like to leave it be.

But going forward there's a question about how to handle changes to fact *values*. One proposal is that we identify (and of course test against) some essential facts that we "care a lot about" (such as 'lsbmajdistrelease") and set some rules, like:

(a) we do not change those in x.y.Z releases 

(b) we highlight it when they DO change in x.Y or X releases

Do also keep in mind that though we can easily fix our own manifests with a regexp match, since the launch of the Forge people have started to use more and more modules maintained by others. Unless the maintainer has already issued an update you're stuck with manually patching an upstream module and carrying that change. Depending on how you deploy your environment this might be difficult to do.

I grep'd my way through forge modules looking for affected modules and there are actually just a handful (3 related to postgresql, and 3 others). I'll ping those authors to let them know. There's already a fix in for puppetlabs-postgresql.

Btw, one last thing: another plug for the recently announced nightly repos, which would have exposed this issue if we'd had repos all in place ahead of time (this change went in two weeks before release).

Thanks!

--

Kylo Ginsberg

ky...@puppetlabs.com

Join us at PuppetConf 2014, September 20-24 in San Francisco

Register by September 8th to take advantage of the Final Countdown —save $149!

[Matt Wise]

I'll start out by saying that we've worked around the problem ... but, when you're operating in cloud and constantly booting new machines, dependencies like Facter are rarely explicitly versioned. That is to say, often you will see someone pin the version of Puppet that they install, but they may not pin the version of Facter because its just one of many Puppet dependencies. That means that its unlikely that people will read the release notes before they find themselves surprised that Facter is suddenly reporting new and interesting information.

I honestly think its better practice to revert the change and then plan a future major version release where you flip that setting. You could add in a big warning-message that says 'hey, in the next release we're going to break $lsbmajdistrelease...' which would get peoples attention to.

All of that said, we're fixed now .. so I'll stop griping. :)

Matt Wise

Sr. Systems Architect

Nextdoor.com

--

You received this message because you are subscribed to a topic in the Google Groups "Puppet Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/puppet-users/Ve0L1iW3NeU/unsubscribe.

To unsubscribe from this group and all its topics, send an email to puppet-users...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CALsUZFHQ_Pho_%2Bq9VCBMdMhe4DjcZRhvmF5NU74wTU-DXoZ9xg%40mail.gmail.com.

[Christopher Wood]

On Thu, Aug 28, 2014 at 08:13:21AM -0700, Matt Wise wrote:
> I'll start out by saying that we've worked around the problem ... but,
> when you're operating in cloud and constantly booting new machines,
> dependencies like Facter are rarely explicitly versioned. That is to say,
> often you will see someone pin the version of Puppet that they install,
> but they may not pin the version of Facter because its just one of many
> Puppet dependencies. That means that its unlikely that people will read
> the release notes before they find themselves surprised that Facter is
> suddenly reporting new and interesting information.
> I honestly think its better practice to revert the change and then plan a
> future major version release where you flip that setting. You could add in
> a big warning-message that says 'hey, in the next release we're going to
> break $lsbmajdistrelease...' which would get peoples attention to.

Humourously, has anybody filed a ticket with Canonical to have Ubuntu not use a dot in their major version number?

> All of that said, we're fixed now .. so I'll stop griping. :)
> Matt Wise
> Sr. Systems Architect
> Nextdoor.com
>

> On Wed, Aug 27, 2014 at 3:51 PM, Kylo Ginsberg <[1]ky...@puppetlabs.com>

> wrote:
>
> On Tue, Aug 26, 2014 at 11:57 PM, Daniele

> Sluijters <[2]daniele....@gmail.com> wrote:

>
> Hey,
> I agree with the spirit of the fix but the fact that it isn't
> mentioned anywhere in the release notes is a bit annoying.
>
> Yep, it's a release notes fail, and it happened because we didn't track
> the change with separate tickets. What happened is we made this change

> as part of adding lsbminordistrelease ([3]FACT-637) and adding the new
> 'os' structured fact ([4]FACT-614), but it wasn't called out

> separately. Anyway that's an explanation, but not really an excuse - we
> dropped the ball on publicizing this change.
> We've added tickets for the changes and pushed updated release notes for

> facter 2.2 [5]here.

>  
>
> I personally also consider this a backwards incompatible release,
> you're changing old behaviour. Albeit for the better, but people
> depended on that behaviour and no prior warning or deprecation warning
> was issued.
>
> Although we clearly should have documented this differently, since it's
> in the wild and there's consensus that this change *is* for the better,
> we'd like to leave it be.
> But going forward there's a question about how to handle changes to fact
> *values*. One proposal is that we identify (and of course test against)
> some essential facts that we "care a lot about" (such as
> 'lsbmajdistrelease") and set some rules, like:
> (a) we do not change those in x.y.Z releases 
> (b) we highlight it when they DO change in x.Y or X releases
>
> Do also keep in mind that though we can easily fix our own manifests
> with a regexp match, since the launch of the Forge people have started
> to use more and more modules maintained by others. Unless the
> maintainer has already issued an update you're stuck with manually
> patching an upstream module and carrying that change. Depending on how
> you deploy your environment this might be difficult to do.
>
> I grep'd my way through forge modules looking for affected modules and
> there are actually just a handful (3 related to postgresql, and 3
> others). I'll ping those authors to let them know. There's already a fix
> in for puppetlabs-postgresql.

> Btw, one last thing: another plug for the [6]recently announced nightly

> repos, which would have exposed this issue if we'd had repos all in
> place ahead of time (this change went in two weeks before release).
> Thanks!
> --
> Kylo Ginsberg

> [7]ky...@puppetlabs.com
> Join us at [8]PuppetConf 2014, September 20-24 in San Francisco
> Register by September 8th to take advantage of the [9]Final

> Countdown —save $149!
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Puppet Users" group.
> To unsubscribe from this topic, visit

> [10]https://groups.google.com/d/topic/puppet-users/Ve0L1iW3NeU/unsubscribe.

> To unsubscribe from this group and all its topics, send an email to

> [11]puppet-users...@googlegroups.com.

> To view this discussion on the web visit

> [12]https://groups.google.com/d/msgid/puppet-users/CALsUZFHQ_Pho_%2Bq9VCBMdMhe4DjcZRhvmF5NU74wTU-DXoZ9xg%40mail.gmail.com.
> For more options, visit [13]https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [14]puppet-users...@googlegroups.com.

> To view this discussion on the web visit

> [15]https://groups.google.com/d/msgid/puppet-users/CAOHkZxOrMRd4Tgki7kv2kzPfrgP9A6nFs0dCMXj2xLZhvhXXkg%40mail.gmail.com.
> For more options, visit [16]https://groups.google.com/d/optout.
>
> References
>
> Visible links
> 1. mailto:ky...@puppetlabs.com
> 2. mailto:daniele....@gmail.com
> 3. https://tickets.puppetlabs.com/browse/FACT-637
> 4. https://tickets.puppetlabs.com/browse/FACT-614
> 5. https://docs.puppetlabs.com/facter/2.2/release_notes.html
> 6. https://groups.google.com/forum/#!topic/puppet-users/gtXrUgQZmJ0
> 7. mailto:ky...@puppetlabs.com
> 8. http://www.puppetconf.com/
> 9. https://www.eventbrite.com/e/puppetconf-2014-tickets-7666774529?discount=FinalCountdown
> 10. https://groups.google.com/d/topic/puppet-users/Ve0L1iW3NeU/unsubscribe
> 11. mailto:puppet-users...@googlegroups.com
> 12. https://groups.google.com/d/msgid/puppet-users/CALsUZFHQ_Pho_%2Bq9VCBMdMhe4DjcZRhvmF5NU74wTU-DXoZ9xg%40mail.gmail.com?utm_medium=email&utm_source=footer
> 13. https://groups.google.com/d/optout
> 14. mailto:puppet-users...@googlegroups.com
> 15. https://groups.google.com/d/msgid/puppet-users/CAOHkZxOrMRd4Tgki7kv2kzPfrgP9A6nFs0dCMXj2xLZhvhXXkg%40mail.gmail.com?utm_medium=email&utm_source=footer
> 16. https://groups.google.com/d/optout

[Atom Powers]

I have been using lsbdistcodename precisely because of the confusion with version numbers in ubuntu. In my environment I can safely assume that there is no difference in the way I deploy to 14.04 vs 14.04.x.

--

You received this message because you are subscribed to the Google Groups "Puppet Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/a984477b-dad8-4717-8e84-a4e410b641fa%40googlegroups.com.

[Ramin K]

On 8/28/14 8:13 AM, Matt Wise wrote:
> I'll start out by saying that we've worked around the problem ... but,
> when you're operating in cloud and constantly booting new machines,
> dependencies like Facter are rarely explicitly versioned. That is to
> say, often you will see someone pin the version of Puppet that they
> install, but they may not pin the version of Facter because its just one
> of many Puppet dependencies. That means that its unlikely that people

We pin Facter and Puppet as well as pull the packages into our own
repo. Puppet moves way too fast and touches way too many things not to
lock it down.

Ramin

[Felix Frank]

+1 on the sentiment, but I'll admit that I have been neglectant
concerning Facter in this regard, so Matt's assumption seems to hold.

...or my glass is just too half full for this job ;-)

Cheers,
Felix

[Daniele Sluijters]

Hi,

I don't mind even changing that stuff in .Z releases but I think .Y is more appropriate indeed. Releasing a new major version of Facter every time a fact is bug fixed seems madness and not something you should get into.

As long as the release notes are in order I think most people have come to expect at least some 'breakage' on .Y releases, regardless of wat semver says (that's not anything personal towards Puppet Labs, it happens on a lot of projects).

-- 

Daniele Sluijters