-
Notifications
You must be signed in to change notification settings - Fork 327
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
docs: add proposal how users should indicate application protocol of a service #553
Conversation
…f a service [ci skip]
5433653
to
ad05cb8
Compare
|
||
## Open questions | ||
|
||
1. What happens if a user defines different `protocol` tag for the same `service` in different `Dataplanes` ? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need this information when generating inbound listeners, right? We generate listener for a given dataplane, so if one DP is defined with TCP then TCP listener will be generated, if DP is defined with HTTP then HTTP listener will be generated.
- api: | ||
rest: | ||
spec: | ||
url: https://generator.swagger.io/api/swagger.json |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What can we do with such information?
LinkerD has this to generate endpoints for which then metrics are collected, but we don't need it once generate listener with http connection manager filter.
- port: 7070 | ||
name: http-metrics # `http` protocol in the `name` | ||
- port: 6060 | ||
name: somethinggrpc # `grpc` protocol in the `name` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What if I have both in the name? Example: grpc-http-bridge
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For now - in order to not make too many changes at once - let's add protocol
and call it a day. As our use-cases get bigger, we may need to consider adding something similar to service profiles, but we can make this decision another time.
Summary