Eric Helms

> This doesn't work. Answers are read before built ins (and tuning is considered a built in): > https://github.com/theforeman/foreman-installer/blob/dcd015ced528a36f5ad4534626e53d68a317ffc1/config/foreman-hiera.yaml#L13-L23 > > Hiera is also not used to determine defaults so...

Could we skip writing empty values to the answer files? Would that solve this problem? Would it create other problems?

> Why is this part of the boot hook? Boot happens only after migrations, and that is why I chose it rather than actual migrations (https://github.com/theforeman/kafo/blob/master/lib/kafo/kafo_configure.rb#L140). I did not want...

Tracking current test scenario that results in a successful install for Foreman: ``` foreman: box: centos7-foreman-nightly ansible: variables: foreman_repositories_environment: staging katello_repositories_environment: staging koji_task_ids: - 356320 foreman_installer_module_prs: - theforeman/foreman/856 - theforeman/foreman_proxy/599...

@ekohl is there a way to verify we can remove it? or is it a drop and see what happens?

Can we test this at a more granular level or a simpler way without having to have an entire pipeline run dedicated to it?

Seems like with this change, and combined with https://github.com/theforeman/kafo/pull/338 handling enable/disable support we could get rid of the need for the answers file all together and rely on pure hiera...

I think there is one fundamental I am missing as to how this works, and whether its a feature of Kafo or a feature of Hiera. What keeps the value...

I think you probably did explain it previously, that doesn't mean I understand all the nuances. So I am still confused a bit. Hiera is considered when calculating the defaults....

So with this change, the answers file should never change as a user tweaks their installation? Further, the implication is that a user should never touch this files by hand...