[helm] Support getting data-source-name from an existing secret about sql_exporter

[allanger]

Ah, I guess I've missed the SQLEXPORTER_TARGET_DSN var. I guess I can just use it, and my problem will be solved, cause I'm only using single-target mode. But I think in general, it would be nice to support multi-target as well, though I'm not sure how

[burningalchemist]

Sounds good to me!

Time-wise, I'd like to finish v0.14 and then declare a feature freeze to work on test coverage, and finish with some static web site with a better documentation approach. So, if there's anything needed from my end to be supported by db-operator, please let me know (or feel free to drop some thoughts under Discussions/Ideas 👍 ).

[burningalchemist]

Hey @allanger, let's keep this issue open since it's somewhat linked with #397 as well.
As for #397, I was carried away by my daily job, and couldn't arrange time to proceed - there are multiple deadlines at the end of the year. 🙂 I'll try to respond and suggest something sooner, so we can merge the PR. 👍

[burningalchemist]

Hey @allanger,

Currently, there's SQLEXPORTER_TARGET_DSN environment variable that's used for DSN. This only works for a single-target mode, though. Maybe you could try to do something around this env if you think it makes sense.

Apart from that, yeah, here's the next milestone for v0.14. I think I'll start working on it next year (or by the end of this year). One of three features in the list is already implemented. So I could prioritise #186 then.

Could you please share which env variables you would use in the last solution?

Cheers!

[burningalchemist]

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 db-operator looks complicated from the beginning anyways. I have some ideas on the env-driven configuration, but need to prototype them first. So I think Helm integration for multi-targets makes sense to look at after #186 is delivered.

[allanger]

We can think about adding some integration for db-operator, since I'm one of maintainers there :)

[lhaussknecht]

Funny - yesterday I started on a PR for exactly this usecase :)

[allanger]

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

[lhaussknecht]

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: ***@***.***>

[burningalchemist]

Cool! I guess there's no overlap then. 👍

[allanger]

Actually, I'd say that this issue can be closed, because my problem was solved by #399

But should we wait for #397 ?

[burningalchemist]

Resolved by #399 and #446.