-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Enhancement]: Support additionalVolumes #10065
Comments
There is a lot of operators which support |
This should be closed as a duplicate of #3693. In general, this requires a proposal (https://github.com/strimzi/proposals). If you are interested in contributing this feature, that would be welcome - writing the proposal would be the first step. I think the preferred solution from the Strimzi side is to use the existing Pod and Container templates and configure the additional volumes / volume mount points there. |
@scholzj I don't mind closing this. I also agree on adding to the existing pod and container templates, but do you want a proposal before i prepare a PR? |
Yes, this is a major enhancement with API impact. So this should have a proposal written and approved first. Of course, if you want to write a prototype implementation to accompany the proposal (to for example make sure it is feasible or when you want to run the Strimzi system tests), it is fine to have a Draft PR for it and we can for example run the System Tests on it. But it will not be merged/fully reviewed before the proposal is approved (and having the prototype PR does not guarantee in any way that the proposal will be accepted of course). (But just to be clear, you are not required to have any kind of prototype implementation to open the proposal. From my own experience, sometimes it helps to write the proposal as you better understand what is needed. But for other proposals it is not really much helpful. So it depends a lot.) |
Thanks for the feedback. I will close this and work on a proposal + a draft PR. |
Related problem
besides the
storage.volumes
used directly for kafka storage, it would be nice to setadditionalVolumes
for things such as extracting logfiles.I won't mind working on the pull request, but I need to make sure there is acceptance of the solution.
Suggested solution
Add additionalVolumes to the CRD
Alternatives
I can not see a way to access the log files with the existing CRD. Everything is either tmpdir with MEMORY as the type (hardcoded), secret+config mappings or the dedicated volumes for kafka storage.
Additional context
My usecase is that I have setup up
spec.kafka.logging.loggers
to haveWhere
authorizerAppender
is a custom logger that saves audit logs to a file. I do not want audit logs to be shown in stdout for security purposes.Using
additionalVolumes
I could map the log directory to a volume shared by a OpenTelemetryCollector which uses a sidecar to read and send the audit logs securely to my audit storage solution.The text was updated successfully, but these errors were encountered: