DevConf.us 2019: Notes and reflections by akofink

[ekohl]

@akofink

It was suggested that some of the lifecycle management part of puppet, namely environments, should be first-class objects in
Foreman, not necessarily associated with just Puppet. The ability to have a Dev → Test → Production promotion of Ansible rules or Salt recipes, for example, is desired.

I’ve been suggesting this in various places. Great to see users agree

@akofink

How to test/gate releases upstream better

New repository for smoke tests

Hello everyone, As a follow up to RFC - Integration Tests & End to End tests I want to create a new repository for this and @rplevka’s provisioning tests. My proposed name is theforeman-smoker. The reason is that theforeman indicates it’s project wide including plugins rather than the single foreman project. Smoker since it’s doing smoke tests. The project will be written in Python 3 and heavily rely on pytest. We will include this in our release pipelines to verify functionality. That means…

@akofink

Perhaps we could add end to end tests in the same repository as the code to increase the liklihood that a feature/bug fixer updates end to end tests.

This has been suggested before but I never liked this. It’s very hard to find which source repositories are actually needed matching your install. Repositories can add integration tests (built into Rails, enabled on our CI) which can test this. Is this not sufficient to catch most issues?

@akofink

iPXE supports ARM iPXE - open source boot firmware [cfg:platform], but does Foreman’s DHCP allow “option 93” mentioned in that doc?

We’re just shipping ISC DHCP by default and the installer can configure it, but this is in no way mandatory and I don’t see why you can’t set it up.

@akofink

When looking for dns conflicts, Foreman queries the dns host in
/etc/resolv.conf instead of the DNS server in the proxy

I thought we had query_local_nameservers for this though I agree this is very ugly and we need to fix this.