Hi,
I really like the points Eric, Wil and Henrik have brought up. Here're
some more from me.
On 2014-08-29 23:11, Kylo Ginsberg wrote:
[Splitting this out of the original thread which was the Facter 2.2.0
announcement.]
On Thu, Aug 28, 2014 at 2:58 AM, David Schmitt <da...@dasz.at
<mailto:da...@dasz.at>> wrote:
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.
There are a couple really good issues here, and I'm torn on the answers:
1) While semver clearly applies to the Facter *API*, I'm not sure if it
provides guidance on Facter *values*. Yes, on the one hand, I could
argue that the values are part of the Facter contract, but that seems
like a contortion of "API". I incline toward treating semver as API-only.
That's only semantic BS. The primary consumer of facter is puppet code
writers. If the meaning of return values of something like sprintf would
change, all hell would break loose. Why should it be different for the
return value of $operatingsystem ?
Semver's exclusion of UIs is due to the fact that users are much, *much*
more flexible to react to changes than deployed code.
2) More importantly, a strict reading of semver as applied to facts
would tie our hands (or force more rapid majors). E.g. I add fact 'foo'
in 3.0, and it turns out to work great on RHEL but is incoherent on,
say, Windows. But it's now out in the wild, so if I'm completely strict
about changes we have to leave it be until 4.0, although that may mean
that more and more Windows users painfully write manifests around the
3.0 behavior.
It's roughly (hand wave) that sort of consideration that led to the idea
floated above of define some "major" facts (and platforms) where we make
guarantees.
To tie (1) and (2) together, there's a case to be made for separating
Facter's API guarantees from its fact value guarantees, and perhaps even
to tiering the latter. The exact details are up for discussion of course.
That is totally legitimate and starting a separate semver stream for the
values just underlines that they too are API (if also perhaps a
different set).
Something that can be done to ease the semver pressure is start
collecting recipes to avoid disaster when the inevitable glitch happens.
For example, if a certain fact produces garbage on a platform and fixing
it would require wide-spread changes, one could add a $FACT_ex fact that
returns the fixed values in a minor version and fold that change into
the normal fact on the next major bump. Or start a versioned facts hash
so that the consumer can choose which version to access. I suggest the
latter because even if the fact-value-semver is decoupled from facter's
semver, manifests will have to deal with a broad range of deployed
versions and having to keep all permutations and bugs straight won't be
easier, just because it now has a version.
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
--
You received this message because you are subscribed to the Google Groups "Puppet
Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/540186DB.8010406%40dasz.at.
For more options, visit https://groups.google.com/d/optout.
