Catalog: support registering in configured datacenter vs defaulting to agent's

[jukie]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request. Searching for pre-existing feature requests helps us consolidate datapoints for identical requirements into a single place, thank you!
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request.
• If you are interested in working on this issue or have submitted a pull request, please leave a comment.

---

Is your feature request related to a problem? Please describe.

For my org we have a few datacenters without Consul servers running so for Catalog Sync I'd like services to be registered in the datacenter configured by cli flag or CONSUL_DATACENTER env var. However, because Catalog Sync doesn't check for this the resulting catalog registration will default to the datacenter of the agent it's communicating with.

Feature Description

Catalog Sync should respect the -datacenter cli flag or CONSUL_DATACENTER env var when registering services

Use Case(s)

Explained above

Contributions

Yes, will open a PR

[david-yu]

@jukie Out of curiosity did this config perhaps not work for you externalServers? This allows you to set the servers you want catalog Sync to point to.

[jukie]

Right but when connecting to those external servers it still won't respect the configured datacenter as a target registration. For example I'm using servers in datacenter A but I want the registered services to be registered under datacenter B. When not set in the catalog registration api call it defaults to the datacenter of the Agent being used and in this example would incorrectly register services under datacenter A even though a -datacenter flag or env var is pointing to datacenter B.

Other components here respect the configured datacenter and do a similar setup as proposed in my PR. This is also the behavior implied by the help text output.

[david-yu]

I have to ask a few more questions to understand his more:

For my org we have a few datacenters without Consul servers running so for Catalog Sync I'd like services to be registered in the datacenter configured by cli flag or CONSUL_DATACENTER env var.

I'm curious how you're able to get datacenters in Consul running without Consul servers? My understanding that a consul datacenter == a consul cluster with a set of Consul servers running.

Is this use case perhaps to registering the same service across multiple Consul clusters, for high availability?

[jukie]

Sorry you're correct and that's a fair question, I mistakenly misrepresented my constraint.

There are consul servers in the target datacenter but for a few reasons I may not be targeting them as the externalServers, the main one being a limitation in how we address consul servers via DNS.

Fixing that is something that will be done with our setup but Sync Catalog should probably be respecting the datacenter flag or env var anyways since the API supports this and is how other components here operate.

If I may ask, is there any reason not to add this change? If the API for catalog registration supports this it seems like this was the intended behavior and was a gap in consul-k8s because in 99% of cases a user would logically be registering services in the same datacenter as the agent sync catalog is communicating with.

At least that's how it appears to be getting used in places like below. It gets the configured datacenter through the main command flags (or env var) and then adds that to the relevant controller or resource and sets the target datacenter in various api calls or uses it for filtering logic.

api-gateway:

consul-k8s/control-plane/api-gateway/cache/consul.go

Line 126 in cc5850e

datacenter: config.Datacenter,

inject-connect:

consul-k8s/control-plane/subcommand/inject-connect/v1controllers.go

Line 141 in cc5850e

Datacenter: c.consul.Datacenter,