Are you using this option today? We are looking to better understand how this option is used to determine how it should look in the near future. Please comment if you
Have any valid use case for an end-user of Foreman to use this installer feature
Use this feature in your development workflow
Are using Kafo in another project (not foreman-installer) that uses this feature
Have any use case for skipping one or more individual checks without skipping checks as a whole
In my experience, this feature seems only useful for developers who might need to skip a check (e.g. system requirements check) in a development or CI environment, while Foreman end users should generally not be skipping any checks.
We are considering whether it is worthwhile to implement granular control over which checks are run and any additional examples would be very helpful in making the decision.
I’m not using this feature anywhere, but I can share, what the original motivation for implementing it was. Many versions ago, we wanted to make sure, that the fqdn is determined correctly, before the installation starts. It took several tries, before we got to reasonable detection. And since it was broken for several releases, we wanted to provide a way to finish the installation even in case, the check fails.
Over time, it became less useful in the foreman-installer. It felt as a good feature for any kind of kafo based installer. However, there don’t seem to be many installers based on kafo.
I’d dare to say, it’s safe to modify or even drop these days. I, as a developer, tend to comment checks in the code if I need to.
In our CI we don’t use --skip-checks-i-know-better because those are usually sane. The thing I run into the most is that on containers the FQDN is not correct, but there the whole install would fail anyway. There I think it makes sense.
A related parameter we have is in Katello where we implement --disable-system-checks (as a custom hook). Perhaps @Marek_Hulan remembers the history of why this is not using the option directly from Kafo.
That custom hook option is used in Katello’s CI because our CI systems have lower specs recommended. Disabling all checks just because of 1 is a bad thing and means we lower our coverage in CI. That’s why I think we need a more fine grained model which allows disabling just that. Even better would be one where we can actually tune memory requirements down (because that’s really the only thing). For example, we can implement a --tuning small option.
IMHO --disable-system-checks implies it’s a normal thing to disable them, but --skip-checks-i-know-better really discourages it. The naming might feel a bit user hostile, but it really drives home the intent. Checks are there for a reason. If a check is bad, it should be fixed or removed.
I would have to agree, small VMs to test automation things often don’t require the hardware a real instance of Foreman or Foreman+Katello would. So having granular checks that can be disabled seems better than a blanket --skip-checks-i-know-better option. A --check-minimum-hw=false or --no-check-minimum-hw tells the reader what is intended. So does --check-fqdn=false or --no-check-fqdn. But being a new Foreman user, and having for moment enough RAM for VMs, I have never used the option, but it did make me curious when reading the --help output to see that, not enough to investigate, but still curious. That my 2c worth.
I think there used to be 2 different types of checks, one is whatever is executable, where --skip-checks-i-know-better was applicable and the second introduced only in katello-installer based on hooks. --disable-system-checks was introduced to signal to ignore these the second type of checks. I hope I remember correctly, it would be good to unify this, unless that already happened. Note that system checks (the first type) don’t have access to the runtime, so hooks based checks are more powerful. They can chech installer argument values, puppet parameter values etc.
So that’s exactly how this came up. We are in the process of merging checks into hooks which also means merging --skip-checks-i-know-better with --disable-system-checks.
We’re evaluating whether the replacement option should have granular control to skip individual hooks. In my experience working with end users these options aren’t commonly used, so perhaps if developers are the primary user of this feature other features might be a higher priority for now.
Thanks everyone for the comments, they are very helpful. If you have further thoughts on it, please do share.
