Skip to content
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

Using an existing / external Consul cluster #325

Open
hamishforbes opened this issue Jun 10, 2021 · 2 comments
Open

Using an existing / external Consul cluster #325

hamishforbes opened this issue Jun 10, 2021 · 2 comments

Comments

@hamishforbes
Copy link
Contributor

I already have Consul deployed and working in my environment and would like to reuse the existing cluster.
There doesn't seem to be an easy way to override the consul hostname though.

I might be missing something but there also seem to be places were hardcoded config is overriding values from $._config which is a bit confusing and tricky to deal with.

For example if i set the consul hostname for the distributor in the place I would expect to:

{
  _config+:: {
    distributorConfig+: {
      'distributor.ring.consul.hostname': 'my-consul.service',
    }
  }
}

It is overriden in https://github.com/grafana/cortex-jsonnet/blob/1.9.0/cortex/distributor.libsonnet#L37 and I have to set those values in $.distributor_args+:: instead / as well.
This appears to be the case for ruler and compactor too.

On a semi-related note, the distributor HA Tracker is also hardcoded to use etcd when it could use Consul as well.
Is there a reason for preferring etcd here? (e.g. performance issues in large production environments for this use case)

@pracucci
Copy link
Collaborator

What we typically do is to override CLI flags in <service>_args (eg. distributor_args+:: { ... }) and not distributorConfig, as you already pointed out.

On a semi-related note, the distributor HA Tracker is also hardcoded to use etcd when it could use Consul as well.
Is there a reason for preferring etcd here?

@gouthamve Could follow up on this. If I remember correctly, there were some perfs / scalability issues.

@hamishforbes
Copy link
Contributor Author

Ok well at least i'm not just doing something stupid!

It does feel a bit odd to have the default configs in the libs be higher priority than the values from _config though.

For this particular issue (consul hostname) would a change abstracting that out to a top level config var be worthwhile?
e.g. $._config.consul.{host,port}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants