Request for enhancement: support structured facts about kitchen-puppet HOT 15 CLOSED

Ok. i did a little research on this.
Currently we have these parameters
facter_version, nil
facterlib, nil
custom_facts, {}
facter_file, nil

so you can specify string facts either inside the .kitchen_yaml via the custom_facts parameter
or via an external file via the facter_file parameter
what we do in both cases is convert these to FACTER_xxx environment variables and set them before we run puppet.

Structured facts enable the facts themselves to be hashes or arrays.
Vagrant is often a good source of implementation for kitchen_puppet.

Vagrant do have an enhancement request
hashicorp/vagrant#4762

benh57/vagrant@770d927

and you can see the full code here:

https://github.com/benh57/vagrant/blob/puppet_structuredfacts/plugins/provisioners/puppet/provisioner/puppet.rb

what they have done (and we should do the same)
is implement a new parameter structured_facts.

if nil then facts work as currently.

if set then we copy the structured facts files to the server and somehow use it.

vagrant copies to /etc/puppetlabs/facter/facts.d/vagrant_facts.yaml
so my guess is that /etc/puppetlabs/facter/facts.d is the default facter folder
so we should copy the structured facts file specified in the structure_file config variable to
/etc/puppetlabs/facter/facts.d
vagrant implement assumes any structured facts are yaml data so we should do the same.

Its probably only a dozen lines of code so fairly easily implemented. just need to test it.
If you would be happy to branch the code and make changes similar to vagrant and add a new parameter structured_facts then i would be grateful and we can merge it in.

Any comments from my collaborators @grubernaut @ytsarev . -)
Is this good idea or a bad idea or can it be improved.
Personally i like simple solutions.

from kitchen-puppet.

actually i looked a little more at the code and we also have an option
install_custom_facts
that creates a file from the custom facts and puts it in a directory.
so i think we just need for structure facts to copy the file to the same place as what we do for install_custom_facts.

from kitchen-puppet.

so you want to separate the handling of structured (new feat) and unstructured (existing feat) facts? for the sake of retro-compatibility?

I have to admit that for now my vision of what to do is obscured by the fact that I don't see the usecase for the existing param install_custom_facts. Does puppet behave differently when we set facts from the environment vars of from files in facts.d?

from kitchen-puppet.

I've been on honeymoon this past week, will get back into this on Monday

from kitchen-puppet.

@looztra as structured facts are seem to be supported since facter 2.0 and it is pretty stable and adopted version, I think we can fully switch to file based facts. I will have advantage of having custom facts defined not only during puppet apply run but also during whole test instance lifecycle.
Please take facterlib into account during PR creation.

from kitchen-puppet.

roger that. Thx for the feedback. I have some time to work on it, I should be able to provide a MR before the middle of next week.

from kitchen-puppet.

@looztra ok - the current implementation of facter is a bit complex -)
facterlib - library of facter
facter_file - file containing facts
custom_facts - hash of facts
install_custom_facts - true of false

we have 4 routines that configure these facts on the puppet apply command

facterlib - this sets the FACTERLIB env variable

custom_facts - if custom_facts is specified this sets the FACTER_xxx variabes from the custom_facts hash parameter.

facter_facts - if facter_file is specified this sets the FACTER_xxx variabes from the facter_file.

prepare_facts - if install_custom_facts and custom_facts hash is specified set then write out custom files to a facter file.

we just want option to have a facter file and pass it to support structured facts.
ok i suggest we just modify facter_facts so if we have a facter file specified we just copy that facter file to the facter_dir (like in prepare facts) rather than convert to env hashes as in facter_facts.

so we just need to change facter_facts to copy the factor file.

Does that sound better? It would be a very simple change. -)

from kitchen-puppet.

We should add some docs to the readme on how facts would after we do this enhancement. -)

from kitchen-puppet.

@neillturner yep, my thoughts on how to implement that converge with yours:

• don't use the env vars when possible
• use a facts file instead

I will integrate the enhancement of the docs in the PR

from kitchen-puppet.

Just in case facterlib is still needed if puppet repo has dynamic generated facts as part of the code and non-standard location (exactly my case)

from kitchen-puppet.

@ytsarev : could you provide a sample repo so that I can test this usecase please?

from kitchen-puppet.

@looztra unfortunately puppet repo i mentioned is company private.
I have in .kitchen.yml

facterlib: /etc/puppet/facter

and the facts threre definied like in https://docs.puppetlabs.com/facter/2.2/custom_facts.html#an-example

So should be pretty easy to simulate.

from kitchen-puppet.

I have a sample repo at:
https://github.com/neillturner/puppet_repo
can we change that? or is it obvious from ytsarev

from kitchen-puppet.

i have created PR Support facter files #93 for review

from kitchen-puppet.

fixed in version 1.0.34

from kitchen-puppet.