Cannot change ALLOWED_CONTENT_CHECKSUMS

[bsteinb]

Version
pulp-operator: 1.0.0-alpha.9
images: 3.32.0

Describe the bug
Changing the value of ALLOWED_CONTENT_CHECKSUMS in settings.py via the pulp_settings field in PulpSpec leads to failed pulp-api and pulp-worker Pods. The logs for these Pods contain the following message:

django.core.exceptions.ImproperlyConfigured: There have been identified artifacts missing checksum 'sha1'. Run 'pulpcore-manager handle-artifact-checksums' first to populate missing artifact checksums.

To Reproduce
On a running instance that is populated with RPM and File content, change PulpSpec.pulp_settings.allowed_content_checksums to enable an additional checksum type, e.g.:

apiVersion: repo-manager.pulpproject.org/v1alpha1
kind: Pulp
...
spec:
  ...
  pulp_settings:
    ...
    allowed_content_checksums:
      - sha1
      - sha224
      - sha256
      - sha384
      - sha512

Expected behavior
Changing the parameter should not lead to Pods failing to start. It seems to me, that the operator should detect changes to said parameter and run the necessary management task pulpcore-manager handle-artifact-checksums as suggested in the logs.

Additional context
None.

[git-hyagi]

Hi @bsteinb,

Thank you for the detailed report!
To make it easier to track the changes in ALLOWED_CONTENT_CHECKSUMS I'm thinking about creating a new Pulp CR field (.spec.allowed_content_checksums) to provide the checksums. From a user perspective, do you think this approach would be fine regarding usability?

So the operator should trigger a reconciliation whenever this new field (.spec.allowed_content_checksums) gets modified and:

• create a k8s job to run the pulpcore-manager handle-artifact-checksums
• rollout/restart the pulpcore pods to get the new configuration

[bsteinb]

To be honest, I don't think the proposed solution is ideal from a usability perspective. Having all Pulp settings under .spec.pulp_settings except for this one is not really intuitive.

On the other hand, I have almost zero experience with making operators, so I cannot judge how difficult it would be to keep the setting where it is now and still do the correct reconciliation.

Anyway, thanks for the quick reply. Good to know that bug reports are still appreciated.

[git-hyagi]

Thank you for the feedback.

Having all Pulp settings under .spec.pulp_settings except for this one is not really intuitive.

Actually, most of the configurations should be done using the fields in .spec and the idea of .spec.pulp_settings was for "custom configurations". For example, the database, cache, secret_key, etc configs are all "abstracted" in .spec and, under the hood, the operator translates/migrates these configs into settings.py.
I understand that this can be confusing because sometimes we need to configure in .spec.<fieldX>, sometimes in .spec.pulp_settings, but we are working to let all "important" fields in .spec.<fieldX> and .spec.pulp_settings should be used only for very specific cases.

Anyway, thanks for the quick reply. Good to know that bug reports are still appreciated.

Sure! Please feel free to open any bugs/rfes that you find relevant. We are open to listening and discussing the issues with the community, your opinion makes the operator better.

[bsteinb]

Thank you for the quick fix. May I ask why the operator limits the valid options to ["md5","sha1","sha256","sha512"], while the Pulp documentation additionally lists sha224 and sha384, which are even enabled in the default setting.

[git-hyagi]

This is to avoid incompatibility with some Pulp plugins (for example, pulp-deb).