Epic: run lifecycle controls — cancel, per-condition TTL, concurrency limits

Open
  • Is something wrong?
#264 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
15/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Active
Tech stack
go, kubernetes
Domain
backend, devops, infrastructure

Research direction

This is a parent epic, not an implementable ticket. Read docs/adr/0006-hub-addon-pattern-for-agent-resources.md and konveyor/enhancements#295, then pick a child (#65 cancel, #66 per-condition TTL, #67 maxConcurrentRuns) in the stated order. Done for this issue is tracking those children, not a code change here.

Written by the indexing model from the issue text.

Description

enhancement kind/feature stream/controller

Summary

Parent thread for the run lifecycle controls specified in ADR-0006 and konveyor/enhancements#295 but not yet implemented: cancellation, per-terminal-condition TTL, and concurrency limiting.

These three are specified together, share CRD surface on AgentRun / AgentWorkflowRun, and have a strict implementation order. Tracking them separately has meant the ordering is implicit and the ADR-0006 delta is not visible anywhere.

Scope

  • #65 — Cancel semantics (spec.cancel, Cancelled phase)
  • #66 — Per-condition TTL pruning
  • #67 — Scaling protection (maxConcurrentRuns)

Ordering

  • #65 → #66 — ttlSecondsAfterCancelled requires the Cancelled phase to exist
  • #65 → #67 — runs queued in Pending behind the concurrency limit must be cancellable before a Sandbox exists

Relationship to shipped work

The controller children of #201 are complete (#198, #199, #200), so terminal-run GC already ships. What landed is a single flat spec.ttlSecondsAfterFinished, following the Kubernetes Job pattern.

ADR-0006 specifies per-condition TTLs (ttlSecondsAfterSucceeded, ttlSecondsAfterFailed, ttlSecondsAfterCancelled), which allow different retention for debugging failed runs versus pruning successful ones. #66 closes that gap between the accepted ADR and the shipped API.

Related, not in scope

  • #192 — agent usage accounting, telemetry, and runaway-run containment. Separate research thread spanning controller/hub/ui/harness, with its own release targets and an explicit requirement to publish an enhancement in konveyor/enhancements before it is implementable. Its containment piece is specified as independent of accounting availability.
  • #102 — Gateway verification Job egress restriction (SSRF). Security hardening, unrelated to run lifecycle.
  • #201 — controller side complete; remaining children are in konveyor/tackle2-ui.

References

  • ADR-0006: Hub addon pattern for agent resources
  • konveyor/enhancements#295 — Hub integration, Run pruning, and Scaling protection sections
Dominant language
Go
Stars
5
Forks
13
Avg merge
4d 2h
Merged PRs (30d)
27

Getting set up

  • Ships a Dockerfile or Docker Compose file
  • Has a pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from konveyor/agentic-controller

All issues in konveyor/agentic-controller

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.