-
Notifications
You must be signed in to change notification settings - Fork 467
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
helm: improve deployment and service manifest #4753
helm: improve deployment and service manifest #4753
Conversation
This user does not have permission to start the build. Can one of the admins verify this patch and start the build? |
1 similar comment
This user does not have permission to start the build. Can one of the admins verify this patch and start the build? |
c631f09
to
a2c7c20
Compare
a2c7c20
to
dd2a705
Compare
Add support for custom resource definition and extend customisation of service specific settings. Signed-off-by: Antoine C <[email protected]>
dd2a705
to
b946b3f
Compare
Ok to test; |
Just wrote this for another helm related PR #3937 but applies here similarly. This PR has been overlooked over a year, sorry for that. The reason this had such a rough path into the git repo is that this repose has been traditionally been the source code which was used to generate Linux packages. Those contributing here (including myself) didn't know enough about helm charts to make decisions about it, thus even the original one has been in contrib. There's however a project called AxoSyslog that aims to be the "cloud native distribution" for syslog-ng. Here's the announcement: https://axoflow.com/cloud-ready-syslog-ng-images/ And here's the repository for the container And the helm chart: I do see some momentum building around that project, transforming the documentation to be cloud first and also adding typical cloud related features such as Prometheus like metrics. I think it would make sense to move helm charts to a better home and AxoSyslog could be that home. What do you think? PS: I am both the original founder of syslog-ng and Axoflow. |
NOTE: I originally copy-pasted the comment above from a different PR as I didn't have too much time to respond properly. I came back now to give you a proper answer :) Those contributing to syslog-ng (including myself) don't/didn't know enough about helm charts to maintain one. Also, container focused behaviour do not always match the expectations for syslog-ng's primarily distro based audience. For this reason, I think it makes sense to separate the original "syslog-ng" we all love and the "cloud-native" distribution of it. The core is the same, but the first is published as source and some distro packages, the second as a container and helm charts. The defaults may also differ: in a container we don't need to handle local logs (e.g. /dev/log or the journal), whereas this is a critical element in a distribution. A few months ago, we decided to create a cloud native distribution of syslog-ng, also adding features that make it more suitable for this context. "We" here means Axoflow, which happens to overlap a lot with the original authors of syslog-ng. Couple of things we added in the last few releases:
While the code level features are distributed as part of syslog-ng (as you can see in the last couple of release announcements) I think AxoSyslog is a better home for helm charts and the container. Here are a few links to get you started:
|
I have now merged the axosyslog-docker and axosyslog-charts repo, so now both sits in the same github repo, here: https://github.com/axoflow/axosyslog/ do you think you could re-open your PR there? |
Hi @bazsi, no problem, I will look into this as soon as I get back to my computer! |
Add support for custom resource definition and extend customisation of service specific settings.
This change is necessary if you want to apply least privilege policy via security context. Here is a custom
values.yaml
that can be used to achieve just that: