We are essentially asking all our users to use our custom tooling where in the past we’ve always aimed at collaborating and integrating existing tools. Please reach out to the Facter team, for example by creating an issue to see if this can be done upstream so we don’t have to ship anything.
Sure, but this will take some time and if we want to merge stuff in core, users need to be able to use it from the day one. So I thought shipping custom/external fact first and then working on getting this integrated could be a way.
Let me first try if this works end to end and then we can open up question of integrating it upstream.
Other duties made me to suspend this effort a bit but I want to get back to it. One thing comes to my mind. Suppose we define some common fact model where we only have one fact to report let’s say OS version. And customer uses RHSM + Puppet:
puppet reports “7.7.1234”
rhsm reports “7.7”
there is a bug (we have missed transformation)
In this case every fact upload would overwrite the value over and over again. How do you think we should solve this?
I really like the idea of common fact model, however this could bring another can of worms. One solution could be defining some kind of importance. Let’s say that puppet < ansible < rhsm. So if rhsm plugin woud report different fact value against already stored different value reported by ansible or puppet, it would be simply dropped.
Ideally we should be able to catch all these special cases since the common model should not be too wide (only selected facts), so this would not happen in the future. But we all know nobody is perfect and there are so many configurations and states.
My biggest concern with this approach of creating a new tool for generating facts is that it requires additional setup by the user to work, and might not be very useful for importing existing hosts in a brown-field setup, which might not have an easy way of installing the new tool on all hosts.
In essence, we would still need to support all the existing fact sources, plus our own custom-made one.
Or as Randall Munroe quite well put it: https://xkcd.com/927/
I’m reffering to ufacter as the new tool and existing sources (puppet/ansible/subman/etc) as the standard tools. While I understand this will give us better facts built just like we want them, it won’t solve the issue of needing to be able to parse facts from the existing sources, and it will require more effort for most users to set up in their environment (assuming most already have some CM tool in place).
This was never considered to be any replacement at any point. I wrote it as a future replacement (maybe) for discovery, but it’s mainly complementary and it would be called from PuppetLabs facter as an external fact.
I did suggest it to the user who asked yesterday in other thread as he literally asked to register a system without puppet. Granted, I extrapolated a bit. However, using a “facter-compatible” tool is something we should not disencourage our users to do. There are probably two dozens of “facter-like” tools floating around.
This could maybe be used for foreman-discovery as well instead of the full-blown facter version.
I do think it would also be nice to know exactly the minimum facts required to register a system. Right now things like ansible just throw the kitchen sink of facts at foreman, and it might be nice to have an option in the ansible plugin to only upload the ‘required’ facts to foreman. I have already thought about working on the foreman plugin in ansible to reduce the amount of stuff it upload to foreman.
That’s exactly what I propose in this thread: CFM - common facts model. I think I am going to start off by defining some basic facts, what the expectations are, the format and start a new thread about it so others can comment on that. I am assuming this would be based on facter3, but we don’t need to stick with everything there - some things are badly designed in facter as I described above. E.g. uptime is reported incorrectly, we can fix that in the CFM easily.
