Use replica-level dataVolumeClaimTemplate and logVolumeClaimTemplate when the shard's field is not set.

[kschoche]

in the case where replicas override dataVolumeClaimTemplates/logVolumeClaimTemplates but the shard does not set it, the replica-level overrides are ignored. This fix prefers the replica settings always as they are more fine grained control points.

I found this while attempting to do something a little bit out of the box: attempting to leverage the operator to migrate a clickhouse cluster from an old storageclass to a new one by leveraging the replica level template overrides.

So I'm going from this type of spec, which uses the defaults for each shard and replica:

spec:
  configuration:
    clusters:
    - layout:
        replicasCount: 3
        shardsCount: 1
    defaults:
      templates:
        dataVolumeClaimTemplate: original-template

And I'd like to migrate to this, which should have the effect of (re)creating the 3 existing replicas using their existing PVs, and adding a new replica to the shard which uses the new storageclass via the logVolumeClaimTemplate + dataVolumeClaimTemplate fields.

spec:
  configuration:
    clusters:
    - layout:
        shards:
        - replicas:
          - name: 0-0
          - name: 0-1
          - name: 0-2
          - name: 0-3
             templates:
              dataVolumeClaimTemplate: some-different-template
              logVolumeClaimTemplate: some-different-template
    defaults:
      templates:
        dataVolumeClaimTemplate: original-template

What happens though, is that the new replica 0-4 is created using the default dataVolumeClaim instead of the one that is specified in the replica-level field of the spec.

While trying to get this to work, I noticed that the replica level dataVolumeClaimTemplate field is ignored if it is not also set in the shard. This PR removes the shard-level check in favour of the replica-level field which allows for finer grained control of the logVolumeClaimTemplates and dataVolumeClaimTemplates.

NOTE: I believe this to be a bug fix since replica level logVolumeClaimTemplate + dataVolumeClaimTemplate configurations are ignored when both shard and replica were set, but it will change behaviour for users:

  - Old behavior: When both shard-level and replica-level volume claim templates (or other settings) were specified, shard-level settings took precedence
  - New behavior: When both are specified, replica-level settings now take precedence

Thanks for taking the time to contribute to clickhouse-operator!

Please, read carefully instructions on how to make a Pull Request.

This will help a lot for maintainers to adopt your Pull Request.

Important items to consider before making a Pull Request

Please check items PR complies to:

• All commits in the PR are squashed. More info
• The PR is made into dedicated next-release branch, not into master branch¹. More info
• The PR is signed. More info

--

¹ If you feel your PR does not affect any Go-code or any testable functionality (for example, PR contains docs only or supplementary materials), PR can be made into master branch, but it has to be confirmed by project's maintainer.