TRITON-2529 Add support in CLB for configuring global timeouts via metadata #8

blovett-ec · 2025-12-15T20:48:14Z

Support changing of the global timeout values, for example when your client/server responses are less frequent than every 55s or 120s. Additionally allows the user to match the client/server timeouts when operating in TCP mode as recommended by haproxy here:

When operating HAProxy in TCP mode, which is set with mode tcp, timeout server should be the same as timeout client. That’s because HAProxy doesn’t know which side is supposed to be speaking and, since both apply all the time, having different values makes confusion more likely.

Update pre-existing documentation for metadata setting/updating to reflect the proper sub-command.

Allow users to customize HAProxy timeout values through the new cloud.tritoncompute:timeouts metadata key. The format uses a JSON-like syntax: {queue:0,connect:5000,client:60000,server:180000} All timeout parameters are optional - unspecified values use defaults: - queue: 0 (unlimited) - connect: 2000ms - client: 55000ms - server: 120000ms Changes: - Add TIMEOUTS_KEY metadata constant - Add TimeoutConfig struct and default constants - Add parse_timeouts() function for parsing metadata - Convert 001-defaults.cfg to Askama template for dynamic rendering - Update configure_haproxy() to use dynamic defaults - Add comprehensive unit tests for timeout parsing - Add documentation in README.md 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <[email protected]>

danmcd · 2025-12-16T15:28:25Z

Confirming: I see a Claude credit in this branch's first commit, so RFD 187 attribution applies, and you're taking responsibility for this, correct?

I've pinged @TritonDataCenter/triton-engineering for this. Also, I will be opening a TRITON- ticket. The lack of description here needs to be fixed, but the summary on this PR is perfect for said ticket. Anything in this PR's conversation that's ticket-pertinent will be pasted there. This will include test-notes and other things that would go in a ticket.

Added copyright notice for Edgecast Cloud LLC.

nshalman

I am comfortable with this. Thank you!

danmcd · 2025-12-16T18:33:16Z

@blovett-ec I will need the following put here for transfer into the ticket:

Why do we need this? IOW: What problem are you solving with this?
How you tested with some modicum of detail.

danmcd

I've added what I think is a decent statement-of-problem-and-solution in the ticket. I will need your testing notes, esp. in light of comments below.

danmcd · 2025-12-16T18:41:41Z

src/lib.rs

    input.trim().eq_ignore_ascii_case("true")
 }

+/// Parse timeout overrides from metadata


Don't we have a Rust crate that'll do this for us? New parsing code feels like a place for security problems, even in a safer language like Rust.

@nshalman may be able to answer this better, esp. with our new Rust monorepo.

Possibly a case of, "yes, but it'd be like bringing an atom-bomb to a knife fight," scenario. Will let @nshalman confirm/deny and mark-as-resolved as appropriate.

Per a discussion with Dan, on the one hand, this syntax is consistent with the one we shoehorned onto the portmap which needed to reasonably extend but be backward compatible with the nodejs implementation.
On the other hand, this is a totally new key so we aren't bound by that constraint and we could use e.g. actual json or whatever.
Another option is to share the code for parsing this mini json-like format rather than having two versions of it... A refactor we could probably get Claude to do...
So yes, the custom "parser" in this PR is a bit of a code smell the more I stare at it...
I might take a swing at consolidating the code and pushing that improvement to this branch...

I have refactored the code. Please take a look, @danmcd and @blovett-ec to make sure you're both okay with the tweak.

works for me.

src/lib.rs

danmcd

Forgot to check request-changes.

danmcd

Removing my request-changes. Still have a question about json parsing, but less blocking.

Reduced to JSON parser question.

- Change TimeoutConfig fields from u32 to std::time::Duration - Support timeout value formats: plain number (ms), 'ms' suffix, 's' suffix - Clamp client/server timeouts to maximum of 60 minutes - Fail on invalid timeout values instead of falling back to defaults - Add getter methods (queue_ms, etc.) for HAProxy template rendering 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <[email protected]>

🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <[email protected]>

danmcd

My +1 stands even after cargo fmt.

danmcd · 2025-12-17T18:02:10Z

src/lib.rs

    input.trim().eq_ignore_ascii_case("true")
 }

+/// Parse timeout overrides from metadata


Possibly a case of, "yes, but it'd be like bringing an atom-bomb to a knife fight," scenario. Will let @nshalman confirm/deny and mark-as-resolved as appropriate.

Extract a generic parse_kv_pairs function to handle the {key:value,...} parsing pattern used by both health check and timeout configuration. - Replace HealthCheckParams tuple with HealthCheckConfig struct - Add set_from_kv methods to HealthCheckConfig and TimeoutConfig - Use strum-derived enums (HealthCheckKey, TimeoutKey) for exhaustive key matching instead of hardcoded strings - Unknown parameters now log warnings instead of returning errors - Add tests for parse_kv_pairs function 🤖 Generated with [Claude Code](https://claude.com/claude-code) ```console $ RUST_LOG=warn cargo test -- --nocapture 2>&1 | grep "error message" Too small port error message: listen port out of valid range (1-65534): 0 Too big port error message: Invalid listen port: 99999 Invalid port error message: Invalid listen port: 99999 ``` Co-Authored-By: Claude Opus 4.5 <[email protected]>

nshalman · 2025-12-19T16:28:04Z

Incidentally, I think for future improvements the time has come to split this out into multiple files. I'm okay with this one landing in one big file.

blovett-ec and others added 3 commits December 10, 2025 08:52

ensure newline at end of file

809a794

correct metadata set/update syntax in documentation

2542681

blovett-ec marked this pull request as ready for review December 15, 2025 22:57

danmcd requested a review from a team December 16, 2025 15:23

danmcd changed the title ~~Add support for configuring global timeouts via metadata~~ MANTA-5495 Add support in CLB for configuring global timeouts via metadata Dec 16, 2025

danmcd changed the title ~~MANTA-5495 Add support in CLB for configuring global timeouts via metadata~~ TRITON-2529 Add support in CLB for configuring global timeouts via metadata Dec 16, 2025

Add copyright for Edgecast Cloud LLC

a548fb1

Added copyright notice for Edgecast Cloud LLC.

nshalman previously approved these changes Dec 16, 2025

View reviewed changes

danmcd reviewed Dec 16, 2025

View reviewed changes

danmcd previously requested changes Dec 16, 2025

View reviewed changes

danmcd reviewed Dec 17, 2025

View reviewed changes

blovett-ec dismissed nshalman’s stale review via 1118c76 December 17, 2025 17:45

blovett-ec and others added 2 commits December 17, 2025 09:54

Document equal client/server timeouts for TCP mode

263aba0

🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <[email protected]>

cargo fmt

0b8df70

danmcd previously approved these changes Dec 17, 2025

View reviewed changes

nshalman dismissed danmcd’s stale review via ddf9529 December 19, 2025 16:17

nshalman approved these changes Dec 22, 2025

View reviewed changes

nshalman merged commit 4f4ac9b into TritonDataCenter:master Jan 5, 2026
1 of 2 checks passed

TRITON-2529 Add support in CLB for configuring global timeouts via metadata #8

TRITON-2529 Add support in CLB for configuring global timeouts via metadata #8

Uh oh!

Conversation

blovett-ec commented Dec 15, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

danmcd commented Dec 16, 2025

Uh oh!

nshalman left a comment

Choose a reason for hiding this comment

Uh oh!

danmcd commented Dec 16, 2025

Uh oh!

danmcd left a comment

Choose a reason for hiding this comment

Uh oh!

danmcd Dec 16, 2025

Choose a reason for hiding this comment

Uh oh!

danmcd Dec 17, 2025

Choose a reason for hiding this comment

Uh oh!

danmcd Dec 17, 2025

Choose a reason for hiding this comment

Uh oh!

nshalman Dec 19, 2025

Choose a reason for hiding this comment

Uh oh!

nshalman Dec 19, 2025

Choose a reason for hiding this comment

Uh oh!

blovett-ec Dec 22, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

danmcd left a comment

Choose a reason for hiding this comment

Uh oh!

danmcd left a comment

Choose a reason for hiding this comment

Uh oh!

danmcd left a comment

Choose a reason for hiding this comment

Uh oh!

danmcd Dec 17, 2025

Choose a reason for hiding this comment

Uh oh!

nshalman commented Dec 19, 2025

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

blovett-ec commented Dec 15, 2025 •

edited

Loading