Add QE agents overview and proposed integration design

[lbarcziova]

No description provided.

[lbarcziova]

@martinky82 could you please go through the document and provide feedback on the summary and next steps?

[martinky82]

Hi,, I went through the document and overall, it a very good description of status quo and where were are heading.
My comments:

• in the state diagram, there should be the same decision and waiting loop in issue-verification agent as in preliminay-testing agent. The work in a very similar way, just the source of test results and the resulting action if tests pass are different.
• the ownership checks in the supervisor agents were because of how the Jotnar pilot was designed - the jotnar bot assigned the issues to itself, hence all the agents checked if the ownership is right. That's not needed anymore.

[qodo-for-packit]

PR Summary by Qodo

Document QE agents overview and label-driven integration design

📝 Documentation 🕐 10-20 Minutes

AI Description

• Document current QE agents, triggers, and lifecycle coverage vs the legacy Supervisor.
• Propose ymir_qe_todo label-driven fetcher + Redis queue integration and rescheduling behavior.
• Outline deployment steps, required code changes, and post-deploy cleanup items.

Diagram

graph TD
  Jira["Jira issue (labels)"] --> Human["QE engineer"] --> QEFetcher["QE fetcher (cron)"] --> Redis["Redis queues"] --> QEProc["QE processor (agents)"] --> Jira
  QEProc --> ET["Errata Tool"]

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Webhook/event-driven trigger (vs cron fetcher)

• ➕ Lower latency vs ~20 minute polling cadence
• ➕ Less repeated JQL scanning load
• ➕ Cleaner “push” model for label changes
• ➖ Requires Jira webhook infrastructure, auth hardening, and reliability guarantees
• ➖ More moving parts (retries, dedupe, DLQ) than a simple cron+JQL loop

2. Fetcher state-based routing (vs pushing to all QE queues)

• ➕ Avoids unnecessary agent invocations when preconditions clearly don’t match
• ➕ Centralizes routing logic in one place (fetcher)
• ➖ Duplicates agent precondition logic and risks drift between fetcher and agents
• ➖ More complex fetcher; harder to evolve agent behavior independently

3. Separate deployments per agent (vs single QE processor)

• ➕ Independent scaling and isolation per workflow
• ➕ Clearer operational boundaries and metrics per agent
• ➖ More idle pods and operational overhead for mostly-API-check workloads
• ➖ More manifests/CI wiring to maintain

Recommendation: The documented approach (label-driven cron fetcher + Redis queues + a single QE processor that relies on agent preconditions and rescheduling) is a good first deployment target: it minimizes infra complexity while enabling the long-running wait/reschedule loops that one-shot compose runs cannot provide. If polling latency or JQL load becomes a problem, the next step to consider is a webhook/event-driven trigger; if queue noise becomes material, consider fetcher-side state routing.

Files changed (1) +180 / -0

Documentation (1) +180 / -0

qe-agents-overview.mdAdd QE agents overview and proposed label-driven integration design +180/-0

Add QE agents overview and proposed label-driven integration design

• Introduces a detailed overview of the three standalone QE agents, where they fit in the Jira→MR→erratum lifecycle, and how they differ from the legacy Supervisor. Proposes a 'ymir_qe_todo' label-driven integration using a cron fetcher, Redis queues, and a single processor deployment, with required implementation steps and cleanup follow-ups.

docs/qe-agents-overview.md

[qodo-for-packit]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)

Great, no issues found!

Qodo reviewed your code and found no material issues that require review

_{To customize comments, go to the Qodo configuration screen, or learn more in the docs.}