Hi @jbrown8380!
This is very broad question and I guess some unpacking needs to be done to answer it fully, so I’ll try my best, but feel free to follow-up with questions for details.
So to have this out of the table as of Foreman 3.0 (with improvements in 3.1) Puppet is now fully optional feature on puppet installation: The Road to Making Puppet Optional
Tho foreman-installer is still depending on puppet-agent to run, but this is quite a lite dependency compared to the puppet-server. We were thinking about implementing the installer in “something else” where ansible would be an obvious choice, but we don’t feel it is worth the effort as there is just too many options to customize and account for and it would be hard to build a tool that would allow such a flexibility to users.
There is forklift project that wraps the foreman-installer with ansible playbooks and is not meant to use in production, but as you say that is not what you’re looking for.
Writing a pure ansible installer would be bit though, but if you’d not aim for the full complexity of foreman-installer it might be doable, there is a POC from @ehelms and @Marek_Hulan foreman_spark you might want to take a look into as a starting point, but it is bit outdated as noone has seen value in rewriting current installer.
I’d also add tho, that installer is really great tool to guide you throught the installation process and I’d not avoid it just because it uses Puppet, but if you really want to, you might install Foreman from code, that is certainly not recommended.
Another option might be to run foreman-installer and remove it once you’re happy with the setup you’ve got. It is definitelly useful to keep the installer configuration around in case you want to adjust your install. But you’d not have puppet around at all on the runing instance.