Add custom Pod labels

[jondoveston]

Add a pod_labels field to each Pulpcore component configuration in the CR.

These custom Pod labels are merged with the current default labels in the settings.PulpcorePodLabels
function that is used across all components to generate the labels for various Pods.

This does not affect the labels for Services, Deployments, StatefulSets and most importantly Pod selectors.
Custom Pod labels will not override the default labels to ensure the immutable selectors do not change.

Closes #1553

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: jondoveston
Once this PR has been reviewed and has the lgtm label, please assign git-hyagi for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[openshift-ci]

Hi @jondoveston. Thanks for your PR.

I'm waiting for a github.com member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[git-hyagi]

/ok-to-test

[git-hyagi]

Hi @jondoveston

Thank you for your contribution!!
For new installations, this change seems to be working ... but I am a little bit worried about existing installations or when users modify the custom_labels.
The deployment.spec.selector field is immutable, so if we try to set new labels, the operator will "crash" with:

"error": "Deployment.apps \"pulp-api\" is invalid: spec.selector: Invalid value: v1.LabelSelector{...MatchExpressions:[]v1.LabelSelectorRequirement(nil)}: field is immutable"}

To be able to modify the pod labels, I think the operator would need to recreate (delete then provision a new one) the deployment with the new pod labels and label selector.
WDYT?

[jondoveston]

@git-hyagi Yes. The selector is immutable and so cannot be changed after creation. The deployment.Spec.Template.ObjectMeta.Labels is mutable so the operator can update it but it will trigger a rolling update to update the pods. I have updated the code to distinguish between pod labels and all the other label sets. I've also renamed the CustomLabels to PodLabels, because it can specifically configure PodLabels now. Also the default labels take precedence so custom PodLabels cannot change them.

[git-hyagi]

oh nice!!
So, since the pod's labels must be a superset of the deployment selector's labels, your idea is to have the PodLabels (which will be the users' custom labels) and the PulpcoreLabels (which are the "old" labels and also those used in the deployment selector).
By using maps.Copy, you avoid errors caused by users trying to overwrite the PulpcoreLabels (PulpcoreLabels take precedence over custom labels).
I liked it!

Everything looks good to me, so, to merge this, would you mind fixing the CI errors

• fix the conflicts
• add the "Closes: #​1553" message to the last commit
• the redis deployment still has the issue with the selector immutable field
  ?

[jondoveston]

@git-hyagi I've fixed the conflicts and updated the last commit message. Can you confirm the operator is still trying to change the immutable pod selector in the Redis Deployment? The code seems ok and my local testing works.