On 3 December 2013 23:27, Adrien Thebo <[email protected]> wrote:
> Structured fact support in Facter has often been compared to unicorns -
> long sought after, greatly desired, and nonexistent. There have been a
> number of proposed implementations but none have managed to make it into
> Facter - either the implementation was incomplete, changed too many things,
> or just didn’t have follow-through. Structured fact support has also been a
> hard requirement for Facter 2, which has meant that Facter 2 itself has
> been in limbo for a long time.
>
> We’re hoping to change this state of affairs, and get a release of Facter
> 2 out that contains structured facts. In order to get something out in
> short order, the initial implementation will support simple data types like
> arrays, hashes, strings, and numbers, and will support basic fact
> composition. The idea is to get the core behavior released into the wild in
> Facter 2, and add more functionality in the Facter 2.x series*.
>
> Normally the next major release of Facter would be based on master, but
> doing so would make things more complicated. The master and stable branches
> have been diverging for over a year, and master is 400 commits ahead of
> stable. The stable branch has only been receiving bugfixes while the master
> branch has been receiving features, but since master has been intended to
> be Facter 2 it’s been receiving breaking features as well as non-breaking
> features. We know the master branch will definitely break things, but we no
> longer know exactly what it’s going to break.
>
> Because the state of master is so uncertain we’ve decided to base Facter 2
> off of stable. Structured facts will be implemented, but Facter 2 won’t see
> a rewrite of all the core facts to minimize the changes released in Facter
> 2. The goal is to base Facter 2 off a known release state and minimize the
> amount of possible breaking changes so that the upgrade from Facter 1 to
> Facter 2 is as painless as possible. Later in the 2.x series we intend to
> start writing new core facts that take advantage to structured data once
> the initial release has landed and works.
>
> Basing Facter 2 off of stable means that we will need to do some
> reordering of the Facter branches. Our CI jobs currently test against the
> master and stable branches, so in order to test Facter 2 against the rest
> of our projects the master branch will need to be changed to the stable
> branch, and the current state of master will be shifted to a new name. I
> propose that we copy the master branch to a ‘next’ branch, and then revert
> the master branch to stable and start work on Facter 2 from there. This
> means that pull requests will be targeted at the right branch by default,
> our CI jobs will continue to behave as normal, and we can synchronize our
> branch strategy with Puppet and Hiera.
>
> Since there are a number of commits in Facter master that we’ve promised
> will be in Facter 2, we’ll be backporting a number of changes from the next
> branch to master. We want to keep the number of backported changes limited
> to minimize the number of changes in Facter 2, but we realize that there
> are changes that many of you have been waiting on for a while. If there are
> specific commits that you really want to see in Facter 2, let us know and
> we can see about getting them backported. And of course, once Facter 2 is
> released we’ll be able to start putting out feature releases much more
> quickly. If things don’t make it into Facter 2 then we can see about
> getting features released in 2.1.
>
> * Tentative roadmap for upcoming Facter releases:
>
>
> -
>
> 1.7.4
> -
>
> release date: mid-December
> -
>
> base: current stable
> -
>
> features: current stable + bugfixes for external facts (#22944,
> #22622)
> -
>
> 2.0.0
> -
>
> release date: mid-January
> -
>
> base: current stable
> -
>
> features: structured facts + short list of candidates from
> (current) master
> -
>
> 2.1.0
> -
>
> release date: TBD
> -
>
> base: future master
> -
>
> features: more facts from (current) master, select facts rewritten
> as structured facts
>
>
So, now that Facter 2.0 is released I'm wondering a bit how the rewrite of
facts to structured versions will be done in a backwards compatible way?
Will all of them get new names?
I guess putting interfaces as network: { interfaces: { eth0: ... } } like
ohai does it would make sense instead of reusing the current name.
But then there are facts like is_virtual that return "true" and "false"
instead of true/false.
I'm also wondering now when it is time to actually start writing it if you
have any thoughts about some overall structure to it before it turns into a
mess? For example ohai has some large top level hashes with a bunch of
facts under each of them: languages, network, filesystem, counters, kernel
& etc. We don't have to copy that structure exactly of course, but it seems
to make sense, and apart from kernel none of those names clash with old
facts.
--
Erik Dalén
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/CAAAzDLd1TP2ZfEYnL8wpEtXVooX5Hv-wf7LREehzG5qXTw2pZA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
