-
Notifications
You must be signed in to change notification settings - Fork 34
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
feat: add $RYUK_CONNECTION_TIMEOUT to configure connection timeout #49
Conversation
main.go
Outdated
func newConfig(args []string) (*config, error) { | ||
cfg := config{ReconnectionTimeout: 10 * time.Second} | ||
|
||
fs := flag.NewFlagSet("ryku", flag.PanicOnError) |
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.
should the FlagSet name be ryuk
or moby-ryuk
?
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 use ryuk.container.timeout
as the property in Java.
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.
This references the name of the program which called by the command line. In main
it shows the following:
$ ./bin/moby-ryuk -h
Usage of ./bin/moby-ryuk:
-p int
Port to bind at (default 8080)
With the flagset:
$ ./bin/moby-ryuk -h
Usage of ryuk:
-p int
Port to bind at (default 8080)
-timeout duration
Connection timeout (default 1m0s)
Thanks @hhsnopek, in which context did you have the need to increase the Ryuk timeout? We added the same to Testcontainers for Java some years ago, so I generally understand the need for it:
In Java, we are using our usual configuration mechanism, which ENV, |
FTR it is "ryuk", not "ryku" 😅 Also, I am not sure we need flags here, as Ryuk isn't intended to be used as a standalone CLI tool, so I would focus on environment variables only 👍 |
1a818d5
to
0ca8aa9
Compare
@kiview My current use cases are:
Go processes are typically configured by flags and environment variables, like Docker's convention where you can use environment variables, flags, and local/global configuration (toml, yaml, json) files. I often see environment variables with a namespace prefix, like @bsideup since Ryuk runs in a docker container and could be configured by an environment variable and a flag passed in |
Thanks for clarification @hhsnopek. I was in the wrong headspace when I looked at the PR yesterday and thought it was about If it is Go idiomatic to have flag as well as ENV I am fine with it, but I would also be fine to only have the ENV variable if it helps to cut down the amount of implementation code, since the Testcontainers projects users of Ryuk can configure the container accordingly through the ENV variable. Was the flag something that made your debugging or development work easier? |
I used the flag in both testing and debugging by updating my local docker image to have a static flag in I'm happy to remove the flag, I don't think Go has an idiom for this. I was mainly sharing common usage/examples 😄 |
Sounds good, then let's just minimize the PR and the implementation. WDYT @mdelapenya? |
33218b2
to
f0427fd
Compare
f0427fd
to
1ca5330
Compare
@mdelapenya is there any pending changes required before merging? I believe all feedback has been addressed, please let me know if I have not. |
@hhsnopek LGTM. Given the fact that @mdelapenya currently takes a bigger responsibility in the maintenance and development of Ryuk and given testcontainers/testcontainers-go#653, is it ok for you if we wait until @mdelapenya is back? |
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, thanks for your patience during the review 🙏
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.
BTW, I've just refreshed myself with the comments, specially #49 (comment) and #49 (comment).
Let's remove the flag support and keep the env variables only, as suggested. Other than that, the code is fine: once there we are ready to merge
I'm revisiting this PR after being back from leave. As mentioned above, we are going to focus on env vars for the connection timeout config. But then, as a consequence, we should remove the already existing flag for the port in which Ryuk is listening, to be consistent while configuring its execution. Probably in a follow-up PR. The flag for the port already exists:
|
* main: Prevent Ryuk from removing itself (testcontainers#53) Bump github.com/stretchr/testify from 1.8.1 to 1.8.2 (testcontainers#61) chore: add dependabot updates (testcontainers#59) chore: sync governance files (testcontainers#58) chore: bump testcontainers-go to v0.18.0 (testcontainers#57) Bump github.com/containerd/containerd from 1.6.8 to 1.6.18 (testcontainers#55)
@hhsnopek thanks for your work here. I'm finally merging this PR, and created a follow-up issue to move all flags to env vars. |
Context
This pull request adds the ability to configure ryku's connection timeout by either a
flag
or environment variableRYKU_CONNECTION_TIMEOUT
and if both are defined the flag is preferred. The goal of this change is to provide a way to define the reaper's timeout when environments take longer than 60 seconds to initialize.