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

[kschoche]

in the case where replicas override data/logVolumeClaimTemplates but the shard does not set these the overrides are ignored, prefer the replica settings always as they are more fine grained control points.

I'm 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 spec, which uses the defaults for each shard and replica:

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

... to this, which should have the effect of (re)creating the 3 existing replicas using their existing PVs, and adding a new one to the shard which leverages the new storageclass via the new log/dataVolumeClaimTemplate's.

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

The end goal being that the existing replicas are slowly replaced with the new ones, after replication has completed and we are left with 3 replicas that each define the correct log/dataVolumeClaimTemplates.

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 log/dataVolumeClaimTemplates.

TODO: upload my tests

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.