[Merged by Bors] - Added functionality to mount extra volumes with files needed for ingestion tasks

[soenkeliebau]

Description

Druid can run ingestions tasks and sometimes it is necessary to supply files for configuring these tasks, like certificates or keytabs..

This PR allows specifying extra volumes that will be added to middlemanager pods as mounts, so that these files can be used when configuring Druid ingestion.

It has been closely modelled (read that as copied and pasted) from stackabletech/nifi-operator#434

Definition of Done Checklist

• Not all of these items are applicable to all PRs, the author should update this template to only leave the boxes in that are relevant
• Please make sure all these things are done and tick the boxes

# Author
- [ ] Changes are OpenShift compatible
- [ ] CRD changes approved
- [ ] Helm chart can be installed and deployed operator works
- [ ] Integration tests passed (for non trivial changes)

# Reviewer
- [ ] Code contains useful comments
- [ ] (Integration-)Test cases added
- [ ] Documentation added or updated
- [ ] Changelog updated
- [ ] Cargo.toml only contains references to git tags (not specific commits or branches)

# Acceptance
- [ ] Feature Tracker has been updated
- [ ] Proper release label has been added

Once the review is done, comment bors r+ (or bors merge) to merge. Further information

[soenkeliebau]

I have not tested this due to lack of knowledge around how best to configure this. @fhennig maybe we can take a look together at this some time?

[sbernauer]

I would prefer putting extraVolumes below clusterConfig. WDYT?
In general presenting this CRD change in Arch meeting would be great, not sure how the prio is though

[nightkr]

I would prefer putting extraVolumes below clusterConfig. WDYT?

Agreed, I think.

[soenkeliebau]

I would prefer putting extraVolumes below clusterConfig. WDYT? In general presenting this CRD change in Arch meeting would be great, not sure how the prio is though

I figured since we discussed the NiFi CRD changes on Wednesday and these are pretty similar I could ride the coattails of that discussion :)

Regarding clusterConfig .. I have no strong preference either way tbh. To my mind clusterConfig was a place to put setting that influence how the product works, whereas I thought of this as more of a "plumbing thing to get the environment right" .... but I think either would make sense.

Since its two against one I'll change it.

[soenkeliebau]

bors r+

[bors]

Build failed:

• All tests passed

[soenkeliebau]

bors r+

[bors]

Pull request successfully merged into main.

Build succeeded:

• All tests passed