[KAJdev]

Adds serverless configuration, worker visibility, and job execution on top of #639. Shared resolution, rendering, and logging keep resource commands consistent. Queue jobs use the SDK data plane; load-balancer requests target the endpoint HTTP URL.

[Copilot]

🟡 Changes recommended

Streaming timeout handling, JSON output consistency, and preservation of omitted GPU exclusions need correction.

4 open issues

• Route rollout messages to stderr in JSON mode · New
• Serialize plain-text responses as JSON strings · New
• Forward and enforce timeout for streaming job runs · New
• Preserve GPU exclusions when omitted from partial edits · New

What changed in this PR

Adds rp endpoint commands for serverless management, building on the shared CLI utilities introduced for pod commands.

Changes:

• Adds endpoint configuration, scaling, worker visibility, releases, and logs.
• Supports queue jobs through the SDK and load-balancer HTTP requests.
• Adds CLI tests for configuration, execution, and error handling.

File	Description
tests/​test_cli/​test_endpoint_command.py	Tests endpoint commands and validation.
runpod/​rp_cli/​main.py	Registers the endpoint command group.
runpod/​rp_cli/​endpoint.py	Implements endpoint management and execution commands.
runpod/​rp_cli/​endpoint_config.py	Builds, validates, and patches endpoint configuration.

_{Review effort: Balanced}

[deanq]

Thanks, this fixes the lagging-release case. The flip side is a PATCH that never creates a release: with the 10s window gone, _follow_rollout now polls until --timeout (600s by default) and only then says "no new release observed". rp endpoint edit follows by default, so if any of the editable fields (scaling or idle timeout, for example) update the endpoint without bumping endpointVersion, a routine edit sits for 10 minutes. Does every PATCH create a release? If not, could _apply skip following when the patch only touches non-release fields, or could the PATCH response tell us whether a release is coming?