-
-
Notifications
You must be signed in to change notification settings - Fork 60
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] Support getting data-source-name from an existing secret #396
Comments
Hey @allanger, Currently, there's Apart from that, yeah, here's the next milestone for Could you please share which env variables you would use in the last solution? Cheers! |
Ah, I guess I've missed the |
Cool, I think it would still be better for the majority of cases. 👍 For multi-target mode, users need to provide way more information in one place, so integrating it with solutions like |
We can think about adding some integration for db-operator, since I'm one of maintainers there :) |
Sounds good to me! Time-wise, I'd like to finish |
Funny - yesterday I started on a PR for exactly this usecase :) |
I might be wrong, since checking from the phone. But are mounting the whole config from the existing secret? If so, it's not resolving the issue, because I need to set the connection string only. A config from a secret is also something in wanted to add, but it's not what we actually need |
Well, that's true. For us it's fine. We are using the secret in combination with collector files from the ConfigMap.
But I think it would be even better to have only the connectionstrings in separate secret(s).
…________________________________
Von: Nikolai Rodionov ***@***.***>
Gesendet: Friday, November 17, 2023 6:19:29 PM
An: burningalchemist/sql_exporter ***@***.***>
Cc: Louis Haußknecht ***@***.***>; Comment ***@***.***>
Betreff: Re: [burningalchemist/sql_exporter] [helm] Support getting data-source-name from an existing secret (Issue #396)
I might be wrong, since checking from the phone. But are mounting the whole config from the existing secret? If so, it's not resolving the issue, because I need to set the connection string only.
A config from a secret is also something in wanted to add, but it's not what we actually need
—
Reply to this email directly, view it on GitHub<#396 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AABCG47AALPPIEVTAGMH623YE6MCDAVCNFSM6AAAAAA7PQMHVSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMJWHAYDINJXGA>.
You are receiving this because you commented.Message ID: ***@***.***>
|
Cool! I guess there's no overlap then. 👍 |
Hey @allanger, let's keep this issue open since it's somewhat linked with #397 as well. |
Context
We are using db-operator that manages our databases, and it is also generating different connection strings for databases and puts them in the k8s secret.
Currently, after a secret is created, we need to get the data from it, put it to the sql_exporter values and then deploy the exporter.
Solution
It would be solved if a helm chart could mount a secret from k8s to the sql_exporter deployment and use it either as a part of config file, or just as a flag.
First solution would require building the config during the startup (most probably with an init container), and it doesn't sound like something that is easy to create and maintain
Second one would require a parameter builder in
_helpers.tpl
, and conditional secret mounts in the deployment, not that bad, I guess. But it also have a drawback, that if you jump into container and run ps, you will most probably see the whole connection string to a database, that also doesn't sound niceAnother option would be just to wait until this feature is released: #186
Than we could just use env vars for everything. I guess, it would be the best solution, actually
Notes
I'm going to work on that myself, once we understand which of solutions works best.
The text was updated successfully, but these errors were encountered: