Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

[nats helm] allow the nats routes to drop the namespace when useFQDN is false #540

Open
NickLarsenNZ opened this issue Jul 28, 2022 · 2 comments

Comments

@NickLarsenNZ
Copy link
Contributor

NickLarsenNZ commented Jul 28, 2022

It would be quite nice to drop the namespace from the short name in the routes.

{{- printf "nats://%s%s-%d.%s.%s:6222," $clusterAuth $name $i $name $namespace -}}

I'd like to create certs for the cluster with the short names as it is only used in a single namespace (bar an external name for remote access during a migration).

I'm not sure anyone else would want this, so I haven't jumped in and create a PR yet, and will hard code the namespace into my certificates for now. If there is interest, I'd be happy to raise the PR.

The two options I see:

  1. Simply drop the namespace from the short name routes (potentially breaking changes for TLS, or multi-namespace, same-cluster setups).
  2. Add an option to toggle the inclusion of the namespace for the short name (defaulting to true to avoid a breaking change).
@NickLarsenNZ NickLarsenNZ changed the title [nats helm] allow the nats routes to drop the namespace from the name [nats helm] allow the nats routes to drop the namespace when useFQDN is false Jul 28, 2022
@caleblloyd
Copy link
Contributor

Is there a "best practice" in k8s for FQDN or no FQDN? I know that using an FQDN with a trailing . can guarantee a single DNS lookup, and no propagation to the external resolver.

@caleblloyd
Copy link
Contributor

Looks like we don't even have the trailing . with useFQDN - we should add that

I would be OK with dropping the namespace from useFQDN: false. It could break users that had useFQDN: false with TLS certificates, although I do not think that would be a very common case. But we would still want to call it out in the release notes

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

No branches or pull requests

2 participants