Hi @Aaditya, this issue has one fundamental problem I've described previously. How Orc will know which password to use during discovery? Having pass stored in k8s pod is not an option. Orc can only connect MySQL instance with a given pass. It has no possibility to ask for credentials from any API. The simplest solution I see is having credentials mapped to IP ranges in Orc's config.

Of course it is possible technically to implement the functionality of querying credentials from external service/database, but the effort for this is significantly bigger. Therefore unless we agree on solution, I'm not able to provide any estimates.

If this is k8s environment, wouldn't it be the easiest/quickest/cheapest solution to have a dedicated Orc instance per cluster?

Hi @Aaditya, this issue has one fundamental problem I've described previously. How Orc will know which password to use during discovery? Having pass stored in k8s pod is not an option. Orc can only connect MySQL instance with a given pass. It has no possibility to ask for credentials from any API. The simplest solution I see is having credentials mapped to IP ranges in Orc's config.

Of course it is possible technically to implement the functionality of querying credentials from external service/database, but the effort for this is significantly bigger. Therefore unless we agree on solution, I'm not able to provide any estimates.

Let’s start from the beginning. Whey you open an empty Orchestrator and go to ‘Discover’ window, you need to point out to any instance of a particular cluster to be discovered (provide IP or FQDN and port). Then Orchestrator tries to connect to a given instance with credentials. So at this moment we need the mapping for Orchestrator to know which credentials to use.

Then it needs to use the same credentials for all discovered instances in this cluster. OK it can be handled somehow, maybe store internally that we are using particular credentials or so. But we need this initial mapping for Orc to know which credentials to use during discovery.

Please ask the customer how would he this feature to work from user point of view. They install Orchestrator, what next? How would they configure different credentials for different clusters.

,

Well, I have no clue. We might use “ClusterAlias” settings to fetch out cluster details from the [orchestrator] database and use a separate config file to define [MySQLTopologyUser] for each of the clusters OR somehow store and query those details from the backend. Ultimately, that file could be mapped into the original config file [orchestrator.conf.json] or using some sort of variables.

Just a theory indeed, would not that be ultra-easy to implement, I believe :-(

Is there any proposal on how to distinguish clusters at the configuration time?

We will need to put these usernames/passwords in Orchestrator’s config file and assign them somehow to clusters. By name? IP range? any other way?