Shouldn't microkernel facts be generated as regular facts?

[hickey]

Created from comment on issue #29 as to not loose the discussion and to allow others to make comments:

A thought I was just having (more of a question) is why was the hardware gathering done this way instead of using the regular Facter interface? If all these gathering processes were written as either Facter modules or even using the facter-dot-d interface, then any one of them blowing up would not disturb the other bits of code gathering information. At lease then in my case only the memory information would be missing.

It would also be easier to add new code to test and generate facts. The other advantage is that running facter on the command line would yield all the regular facts along with the the ones being created by the hanlon code.

Would not be that much trouble to break it apart and make it Facter modules. Although the more I think about it, the more I like adding it as facts-dot-d scripts. One of the principle reasons being that it would make it pretty easy to interface to an external PAAS system through a hook (yes the microkernel needs to support an easy way for someone to drop scripts in a directory and have them executed prior to and after registration--maybe even at each checkin) to retrieve information and drop a JSON/YAML/text file in the facter-dot-d directory to add PAAS values as facts. This would allow Hanlon tags to be created from exposed PAAS information.

[tjmcs]

Keep in mind this code was written about 4 years ago; so things have changed significantly in the Facter world from what was available then. If you have a method in mind for modifying the current Microkernel Controller so that it uses a more "standard" way of extending the set of facts typically returned by Facter (allowing you to pull in external data from sources like lshw, lscpu, and ipmitool that are not typically returned by Facter) then I would fully support efforts by anyone (including yourself) to modify the existing Microkernel Controller code to make that process more robust.

In fact, if we took such an approach we might even have a mechanism that we could use to dynamically modify the facts that are returned to Hanlon by the Microkernel Controller on the fly. Hanlon actually is now providing a cloud-config to the Microkernel as part of the Microkernel boot process, and that cloud-config could very easily be extended to give users the ability to extend the facts that are reported back to Hanlon (in effect, adding additional facts to the set of facts that are returned by the Microkernel as part of that cloud-config). Thoughts?

[hickey]

Sure, I certainly don't know the full history of Hanlon and its lineage. I can appreciate that the way things were written were due to the facilities of the day.

I think you are starting to see the potentials that I am seeing. Giving the ability of external systems to track/modify the workflow process that a machine is processing under Hanlon. Yes, it would become very easy for cloud-config to include a number of static facts that then are provided in the facter output to be seen by Hanlon. That can then be used to decide the next microkernel image to boot or to provide basic state information between boots to support a workflow.

It will take me a couple of days to find the time to convert the code and generate a PR for people to view and comment on. Probably by the end of the weekend it should be ready.