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

[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

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