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

[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!

[David Schmitt]

On 2014-08-28 00:51, Kylo Ginsberg wrote:
> 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

Strict semver would suggest that (major) changes to values be marked
with an increment in the major version.

If it is properly documented though, manifests can conditionalize any
changes on $::facterversion. Annoying, but doable if properly documented.


Regards, David
--
* Always looking for people I can help with awesome projects *
G+: https://plus.google.com/+DavidSchmitt
Blog: http://club.black.co.at/log/
LinkedIn: http://at.linkedin.com/in/davidschmitt

[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.

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

[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