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

Use dns target for urls in interdomain and floating interdomain scenarious #1507

Open
8 of 9 tasks
denis-tingaikin opened this issue Sep 5, 2023 · 4 comments · May be fixed by #1571
Open
8 of 9 tasks

Use dns target for urls in interdomain and floating interdomain scenarious #1507

denis-tingaikin opened this issue Sep 5, 2023 · 4 comments · May be fixed by #1571
Assignees
Labels
question Further information is requested

Comments

@denis-tingaikin
Copy link
Member

denis-tingaikin commented Sep 5, 2023

Overview

Currently, we're using '@' to determine is the network service or network service endpoint related to the some another (external) domain.

For example,

my-service@my-domain means that my-service is located in the remote domain my-domain.

This is working fine, but we could try to support dns target pattern from the grpc.

dns:[//authority/]host[:port] – DNS (default)

1. host is the host to resolve via DNS.
2. port is the port to return for each address. If not specified, 443 is used (but some implementations default to 80 for insecure channels).
3. authority indicates the DNS server to use, although this is only supported by some implementations. (In C-core, the default DNS resolver does not support this, but the c-ares based resolver supports specifying this in the form "IP:port".)

Source: https://grpc.github.io/grpc/core/md_doc_naming.html

Example

At this moment endpoint entries in the registry are

name: nse-1
url: "tcp://${nsmgr-proxy-ip-address}"

With this feature we'll able to use this

name: nse-1
url: "dns://${my-own-dns-server}/${nsmgr-proxy-service-name}"

Pros/cons

Pors:

  1. Use tested standard from the grpc
  2. Add an option to use custom DNS servers in the interdomain tests.
  3. Simplify the system (we dont need extra mapping or registry-proxy component)
  4. Do not need to add dns proxying in interdomain examples (in other words we could super simplify this https://github.com/networkservicemesh/deployments-k8s/tree/main/examples/multicluster/usecases/interdomain_dns

Cons:

  1. Backward compatibility

References

https://networkservicemesh.io/docs/concepts/k8s/

Decomposition

  • Rework swapIP chain element and its tests ~ 4h
  • Rework dnsdiscover chain element and its tests ~ 4h
  • Reowork sandbox testing ~ 4h
  • Stabilize interdomain sandbox test~ 4h
  • Stabilize floating interdomain sandbox test~ 4h
  • Rework interdomain dns example~ 4h
  • Rework floating interdomain dns example~ 4h
  • Rework monolith dns example~ 4h
  • Risks
@denis-tingaikin
Copy link
Member Author

@edwarnicke What do you think?

@denis-tingaikin denis-tingaikin added the question Further information is requested label Sep 5, 2023
@denis-tingaikin denis-tingaikin self-assigned this Nov 7, 2023
@denis-tingaikin denis-tingaikin changed the title Get rid of using '@' in interdomain NSM scenarious Use dns target for urls in interdomain and floating interdomain scenarious Nov 7, 2023
@denis-tingaikin
Copy link
Member Author

@edwarnicke
Copy link
Member

@denis-tingaikin Could you point me to the current URI standard we are using that you are proposing replacing? I'd like to make sure we are covering all the cases reasonably.

@denis-tingaikin denis-tingaikin linked a pull request Jan 23, 2024 that will close this issue
9 tasks
@denis-tingaikin
Copy link
Member Author

@edwarnicke I've implemented this based on https://grpc.github.io/grpc/core/md_doc_naming.html without any modifications. Now, NSM, built on this PR #1571 is  able to work with the DNS grpc target.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
Status: Moved to next release
Development

Successfully merging a pull request may close this issue.

2 participants