-
Notifications
You must be signed in to change notification settings - Fork 137
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
Add in --duplex flag to run HTTP and GRPC servers on the same port #931
Conversation
Signed-off-by: Priya Wadhwa <priya@chainguard.dev>
Thanks! Let's hold this until the new year, and we can cut a new release at the same time. |
@priyawadhwa Is there any change in behavior between serving gRPC on its own port and duplex? Any differences for metrics? |
There shouldn't be! |
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.
Awesomesauce!
Signed-off-by: Priya Wadhwa <priya@chainguard.dev>
Thanks y’all, I’ll test out these changes after the holidays! |
cmd/app/serve.go
Outdated
@@ -81,10 +96,11 @@ func newServeCmd() *cobra.Command { | |||
cmd.Flags().String("tink-keyset-path", "", "Path to KMS-encrypted keyset for Tink-backed CA") | |||
cmd.Flags().String("host", "0.0.0.0", "The host on which to serve requests for HTTP; --http-host is alias") | |||
cmd.Flags().String("port", "8080", "The port on which to serve requests for HTTP; --http-port is alias") | |||
cmd.Flags().String("grpc-host", "0.0.0.0", "The host on which to serve requests for GRPC") | |||
cmd.Flags().String("grpc-port", "8081", "The port on which to serve requests for GRPC") | |||
cmd.Flags().String("grpc-host", "0.0.0.0", "[DEPRECATED] The host on which to serve requests for GRPC") |
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.
I would prefer we don't deprecate these flags, because there are no plans to cut a new major release of Fulcio anytime soon, and ideally we don't mark something as deprecated right after we cut 1.0.
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.
If we eventually plan to remove them (which I think makes the most sense) then it's best to deprecate them sooner. IIUC we'll still maintain support for at least a few releases or a few months (whatever the policy comes up with suggests).
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.
I don't think it's a great look to deprecate functionality right after we've introduced it as stable. I know it's a tiny part of the service, but I think we shouldn't begin deprecation of features right after a 1.0 release until we start thinking about a 2.0 release, and right now, I don't see any features in the pipeline to need a 2.0 release.
cmd/app/serve.go
Outdated
cmd.Flags().String("grpc-host", "0.0.0.0", "The host on which to serve requests for GRPC") | ||
cmd.Flags().String("grpc-port", "8081", "The port on which to serve requests for GRPC") | ||
cmd.Flags().String("grpc-host", "0.0.0.0", "[DEPRECATED] The host on which to serve requests for GRPC") | ||
cmd.Flags().String("grpc-port", "8081", "[DEPRECATED] The port on which to serve requests for GRPC") |
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.
One other issue is by deprecating these, we remove the ability to expose the service only on gRPC, which is removing functionality.
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's the use case for GRPC only? My guess is there's a pretty small subset of people running their own Fulcio to begin with, and I'm not sure how likely it is they'd specifically want to run only GRPC. It's just a hunch, but I'm guessing removing this functionality probably wouldn't have much of an effect on users 🤔
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.
It might affect those who run their own infrastructure.
cmd/app/serve.go
Outdated
cmd.Flags().String("metrics-port", "2112", "The port on which to serve prometheus metrics endpoint") | ||
cmd.Flags().Duration("read-header-timeout", 10*time.Second, "The time allowed to read the headers of the requests in seconds") | ||
cmd.Flags().Bool("duplex", false, "experimental: serve HTTP and GRPC on the same port instead of on two separate ports") |
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 do you think about not adding any flags, but changing the behavior such that when the HTTP and gRPC ports match, we use duplex?
This has a few benefits:
- No deprecations needed
- No breaking changes, since it would not have been possible to set the port values to be the same previously
- No additional flags, which I always see as a win
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.
Hmm it would work, but as a user I don't find it very intuitive. As a user I'd expect that setting --port
and --grpc-port
to the same value would cause an error. I'd still prefer to deprecate the grpc flags and have one --port
flag to expose everything on, mostly because I think longterm it'll be cleaner, easier for users to understand, and because I don't see a use case for GRPC-only functionality.
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.
I see the addition of this change as fixing the error of setting the ports to be the same, rather than adding new functionality. I also would prefer to not use duplex
as a flag name since that's exposing implementation details.
Signed-off-by: Priya Wadhwa <priya@chainguard.dev>
Signed-off-by: Priya Wadhwa <priya@chainguard.dev>
Discussed with @haydentherapper and made the following changes:
@haydentherapper this is RFAL. |
Signed-off-by: Priya Wadhwa <priya@chainguard.dev>
This should be RFAL! |
Codecov Report
📣 This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more @@ Coverage Diff @@
## main #931 +/- ##
==========================================
+ Coverage 53.97% 54.08% +0.11%
==========================================
Files 38 38
Lines 2366 2424 +58
==========================================
+ Hits 1277 1311 +34
- Misses 996 1016 +20
- Partials 93 97 +4
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
cc @bobcallaway for another look |
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.
LGTM, just needs to be rebased for go.mod
Signed-off-by: Priya Wadhwa <priya@chainguard.dev>
Rebased! could i please get another lgtm? |
also adds in a unit test for this. we can optionally start trying this out in staging, and if it works well we can consider deprecating the previous two-port solution.
Signed-off-by: Priya Wadhwa priya@chainguard.dev
Release Note
Add in --duplex flag to run HTTP and GRPC servers on the same port
cc @vaikas