<div dir="ltr"><div>I certainly share your interest in this matter. Thank you for bringing this up. I have some questions, and I also want to share some complicating aspects that I'm not entirely so sure what to do about as of yet.<br></div><div><br></div><div>## Questions</div><div><br></div><div>What did you imagine going in SILENCED_SYSTEM_CHECKS in pulpore.git?<br></div><div><br></div><div>## Complications</div><div><br></div><div>We tried to expand the checks you contributed with the FIPS epic for 3.11 and we ran into several problems causing us to conclude we couldn't use the django checks mechanism. Here's what we got stuck on:</div><div><br></div><div>1. The checks are not run at application start time. This is a problem because the things we are checking for are settings which users can change at any point, not just 'deploy' time. If we start running them with each application start, the application itself should just run them.<br></div><div><br></div><div>2. While (1) is a solvable problem, getting every environment to "use the checks" when the application itself doesn't run automatically is a constant uphill battle. As of now we have: the katello installer, the pulp installer, openshift one-off deployments, containers built by galaxy_ng, the operator, official containers built by pulp, containers built by users. For this reason having all the checks run at startup is what we went with for the fips checks and if Pulp takes longer to startup that would be ok.</div><div><br></div><div>There are two downsides with having the checks run by the application at startup:<br></div><div>* It's startup overhead. This is why the Django checks framework doesn't do it. As of now though, our checks aren't expensive enough to make it prohibitive so for Pulp this is ok.</div><div>* You have to start pulp to run the checks. So our ideal situation is where the same checks are runnable by the django checks mechanism, and at application start time.</div><div><br></div><div>We've been discussing this at the pulpcore meetings. What do you think about all this?<br></div><div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 11, 2021 at 10:34 AM Ewoud Kohl van Wijngaarden <<a href="mailto:ewoud%2Bpulp@kohlvanwijngaarden.nl">ewoud+pulp@kohlvanwijngaarden.nl</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello everyone,<br>
<br>
Django has a checks framework[1] which is exposed via django-admin check <br>
and this means there's also pulpcore-manager check.<br>
<br>
When I introduced the new default deployment layout[2], I implemented a <br>
check for storage paths[3] to verify settings.MEDIA_ROOT and <br>
settings.FILE_UPLOAD_TEMP_DIR are on the same filesystem, following the <br>
general recommendation to make moves super cheap. This is an example of <br>
a deploy only check since it only makes sense on the actual system. <br>
Those are only run when --deploy is passed to pulpcore-manager check.<br>
<br>
Checks are great, but if nobody runs them they're useless. That means we <br>
should run them. To do so, I opened a PR to our puppet-pulpcore module <br>
to run it as part of the acceptance tests. This generates a list of <br>
errors/warnings[4] that I think are invalid. Checks can be silenced via <br>
a setting[5].<br>
<br>
When there is a built in check mechanism that is also extendable in <br>
plugins, it makes it easier to verify an installation works. This can be <br>
integrated into debug procedures and tools like sosreport.<br>
<br>
IMHO the default SILENCED_SYSTEM_CHECKS should live in pulpcore.git <br>
because it's the application itself that determines what's relevant. An <br>
installer (pulp_installer and foreman-installer) can then rely on this <br>
without having to duplicate it. Ideally Pulp's CI is also modified to <br>
run pulpcore-manager check. Depending on how it's tested either with or <br>
without --deploy.<br>
<br>
The concrete question now is, do people agree this is a sensible path? <br>
If so, can we ship a clean config with SILENCED_SYSTEM_CHECKS configured <br>
so that out of the box it's clean and CI to keep it clean?<br>
<br>
Regards,<br>
Ewoud Kohl van Wijngaarden<br>
<br>
[1] <a href="https://docs.djangoproject.com/en/2.2/topics/checks/" rel="noreferrer" target="_blank">https://docs.djangoproject.com/en/2.2/topics/checks/</a><br>
[2] <a href="https://github.com/pulp/pulpcore/commit/f8a8c64bb28cbe3908720ea56f417312a4389862" rel="noreferrer" target="_blank">https://github.com/pulp/pulpcore/commit/f8a8c64bb28cbe3908720ea56f417312a4389862</a><br>
[3] <a href="https://github.com/pulp/pulpcore/blob/master/pulpcore/app/checks.py" rel="noreferrer" target="_blank">https://github.com/pulp/pulpcore/blob/master/pulpcore/app/checks.py</a><br>
[4] <a href="https://github.com/theforeman/puppet-pulpcore/pull/155#issuecomment-741083088" rel="noreferrer" target="_blank">https://github.com/theforeman/puppet-pulpcore/pull/155#issuecomment-741083088</a><br>
[5] <a href="https://docs.djangoproject.com/en/2.2/ref/settings/#std:setting-SILENCED_SYSTEM_CHECKS" rel="noreferrer" target="_blank">https://docs.djangoproject.com/en/2.2/ref/settings/#std:setting-SILENCED_SYSTEM_CHECKS</a><br>
<br>
_______________________________________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://listman.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://listman.redhat.com/mailman/listinfo/pulp-dev</a><br>
<br>
</blockquote></div></div>