On Wed, Apr 2, 2014 at 12:33 AM, Erik Dalén <[email protected]>wrote:
> > 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? > For cases where structured data was represented as dynamic/flat facts it should be straightforward to coalesce these in a single structured fact. For the EC2 facts I've converted the actual fact generation to a single structured fact (http://goo.gl/3tKjDE) which I then unpack into flat dynamic facts for backwards compatibility (http://goo.gl/IrwDIt). This pattern should be readily applicable to most of the other cases of converting dynamic facts to structured facts. > 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. > And this is where things get really fun. I'm interested in exploring an approach where facts can be versioned to allow rewritten facts to coexist safely. The version of a specific facts of all facts can be determined at runtime so that we can start implementing backwards incompatible changes without breaking APIs. For instance we can implement a new version of is_virtual to return booleans, and version it such that it's non-default in Facter 2 but can be enabled, and in Facter 3 it is default but users can opt for the old behavior. When working on Facter 2.0.1 we realized that solving this would be something that required some serious time and thought, and so we opted to defer on it for the sake of being able to ship _something_. Because of this we yet don't have a lot of concrete strategies for addressing this. If anyone has more solutions for how we can manage these sort of challenges I'm all ears. :) > 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. > I agree that it would be good to have better namespacing in Facter, and now is the time to start creating these. There are a couple of approaches here. First off, as part of Facter 2 there is a new way of resolving facts in a piece-wise manner, called aggregate resolutions ( https://github.com/puppetlabs/facter/blob/master/lib/facter/core/aggregate.rb). This allows a single fact resolution to be built up with multiple blocks that are evaluated and then combined. This is specifically built for things like network information where you may have a very deeply nested structure of interface facts, available networking protocols, and whatnot. Moreover these facts can be extended by custom facts without having to clobber or override existing resolution implementations. The docs at http://docs.puppetlabs.com/facter/2.0/fact_overview.html detail the new functionality that's available. This was my best effort to solve the problem of namespacing and building up complex structures, but I'm still waiting to see how useful it ultimately is. Depending on how it's used there may be some modifications to make aggregate resolutions easier to understand and create. The other solution for this problem is to introduce the concept of namespaces into Facter. This has been discussed in the past and there have been some implementations created, but nothing has been merged into core. It is a potential option, and depending on how things go we may implement this to solved the described problem. But considering the amount of unknowns we have in Facter 2, I think that right now we should wait and see how the new features in Facter 2 are used. Facter 2 has been stalled for so long because we tried to solve all problems at once and got stuck aiming for perfection. This time I want to see how the new functionality works, how people want to solve issues with fact compatibility issues, and so forth. -- Adrien Thebo | Puppet Labs -- 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/CALVJ9S%2BKgvAUZbULqkah55HrnvgQ-MvhF--nbDLX0Yozar-TUg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
