[Pulp-dev] Run pulpcore-manager check --deploy
bmbouter at redhat.com
Thu Mar 11 20:26:55 UTC 2021
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.
What did you imagine going in SILENCED_SYSTEM_CHECKS in pulpore.git?
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:
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.
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.
There are two downsides with having the checks run by the application at
* 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.
* 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.
We've been discussing this at the pulpcore meetings. What do you think
about all this?
On Thu, Mar 11, 2021 at 10:34 AM Ewoud Kohl van Wijngaarden <
ewoud+pulp at kohlvanwijngaarden.nl> wrote:
> Hello everyone,
> Django has a checks framework which is exposed via django-admin check
> and this means there's also pulpcore-manager check.
> When I introduced the new default deployment layout, I implemented a
> check for storage paths to verify settings.MEDIA_ROOT and
> settings.FILE_UPLOAD_TEMP_DIR are on the same filesystem, following the
> general recommendation to make moves super cheap. This is an example of
> a deploy only check since it only makes sense on the actual system.
> Those are only run when --deploy is passed to pulpcore-manager check.
> Checks are great, but if nobody runs them they're useless. That means we
> should run them. To do so, I opened a PR to our puppet-pulpcore module
> to run it as part of the acceptance tests. This generates a list of
> errors/warnings that I think are invalid. Checks can be silenced via
> a setting.
> When there is a built in check mechanism that is also extendable in
> plugins, it makes it easier to verify an installation works. This can be
> integrated into debug procedures and tools like sosreport.
> IMHO the default SILENCED_SYSTEM_CHECKS should live in pulpcore.git
> because it's the application itself that determines what's relevant. An
> installer (pulp_installer and foreman-installer) can then rely on this
> without having to duplicate it. Ideally Pulp's CI is also modified to
> run pulpcore-manager check. Depending on how it's tested either with or
> without --deploy.
> The concrete question now is, do people agree this is a sensible path?
> If so, can we ship a clean config with SILENCED_SYSTEM_CHECKS configured
> so that out of the box it's clean and CI to keep it clean?
> Ewoud Kohl van Wijngaarden
>  https://docs.djangoproject.com/en/2.2/topics/checks/
>  https://github.com/pulp/pulpcore/blob/master/pulpcore/app/checks.py
> Pulp-dev mailing list
> Pulp-dev at redhat.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pulp-dev