-
Notifications
You must be signed in to change notification settings - Fork 156
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
This implements more sleeps when clients are expected to poll #347
base: main
Are you sure you want to change the base?
Conversation
Because this has the potential to add artificial delays in something like a CI environment, I am particularly concerned about the "default enabled" for the new feature. The worst case is up to 5 seconds per CA issuance, although that could be multiplied a bunch depending on what is being done. I'm not sure what the guiding principal is for this, so I went with consistency of existing behavior, but happy to reverse it. |
This seems reasonable to me! The other approach that comes to mind would be to instead add new |
I like the idea of consolidating and deprecating. Having 2 things under the VA flag is a bit of a code smell. Since it's a new interface, I'll collapse it down to just As a draft proposal, I think VA should control both VA and CA (despite the name, because users in this configuration already have delays), emit deprecation warnings if present, and favor Summary:
All combinations would log their eventual configuration, integer parse errors are handled by treating the env var as missing ( Sound reasonable? |
Yep, sounds like a good plan to me. |
Specifically this adds two additional delay points: - Between completing validation but before updating the order state - After signing the certificate and before marking it as ready It also completely refactors how these sleeps are controlled, by replacing PEBBLE_VA_* with a single PEBBLE_SLEEPTIME environment variable.
e124408
to
318c1f6
Compare
In theory this is ready, however I have two concerns:
|
Should not be merged until #351 is handled, as it will increase the polling and make failures more likely. |
Hey folks, noticed that this PR ended up stalling but I am possibly looking for some of these sleeps to test timeouts. Any thoughts on how to proceed? Anything changed since 2 years ago? I might just end up trying to find a way around this, but I'm was thinking of trying to use this to test post-challenge certificate order timeouts. |
I drifted away from the project, but it looks like #351 is handled, so I can clean up the PR and re-submit it. edit: wrong account, but it's still me. |
@tiedotguy I'm going to look to unit testing for the thing I need to test, so no worries if this might be a challenge to implement. I'm just looking to test vancluever/terraform-provier-acme#349, but can probably just test what it's translated to in lego configuration itself. I haven't reviewed the code too much on the pebble side to know exactly where the sleep would need to be inserted anyway, and I'd need it to be static value (or at least a minimum value, versus the random sleep that I think happens right now). |
Specifically this adds two additional delay points:
The first is controlled by the existing PEBBLE_VA_* environment variables, and the second is controlled by equivalent PEBBLE_CA_* environment variables.
It also corrects a minor typo in the README.md (default is 5s, not 15s), and removes shadowing of the internal
len
function.