Gate SkillCollection / run readiness on the SkillCard Resolvable condition

Open
  • Is something wrong?
#194 1 comment 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
35/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Active
Tech stack
go, kubernetes
Domain
backend, infrastructure

Research direction

Start with SkillCollection.checkSkillCardRef in internal/controller/skillcollection_controller.go and classifyResolveError in internal/controller/imageresolve.go. Read the related readiness and AgentRun admission paths, then settle how Resolvable=False and Unknown should be handled, including the bare-404 caveat. Done means the admission behavior is decided and covered by appropriate controller tests.

Written by the indexing model from the issue text.

Description

Background

#188 added a best-effort Resolvable condition to image-backed SkillCards
(ArtifactPresent / ArtifactMissing / ResolveInconclusive) so a phantom
image ref — well-formed, Ready=True, but with no manifest in its registry — is
surfaced before run time, which is the point of #187.

Today that condition is informational only. Nothing consumes it, so it does
not yet prevent the failure #187 set out to catch.

Problem

SkillCollection.checkSkillCardRef
(skillcollection_controller.go:174)
gates a collection's readiness only on the card's Ready condition. So a phantom
card (Ready=True, Resolvable=False) still makes its collection Ready, and a
run using that collection is still admitted — then ImagePullBackOffs at pod
time. The same is true for an AgentRun that references a phantom card directly.

Proposal

Decide how Resolvable should feed collection and run admission. Two design
calls to settle:

  1. What may block — only False, never Unknown. Resolvable=Unknown is
    best-effort inconclusive (a private registry the controller can't
    authenticate to, or a transient network error); the pod may still pull it
    with its own imagePullSecrets. Gating on Unknown would break every
    private image, so only a definitive Resolvable=False is a candidate to
    block.

  2. Hard gate vs. soft warning. Does False make the collection NotReady /
    refuse the run (a real run-admission gate), or just annotate a warning and
    let the operator's requested run proceed? A hard gate changes admission
    semantics.

Caveat to resolve before any hard gate

classifyResolveError
(imageresolve.go)
currently maps a bare 404 (no MANIFEST_UNKNOWN / NAME_UNKNOWN code) to
Missing. Some registries answer 404 for private repos to avoid leaking
existence, so a pullable private image could report Resolvable=False. If
False becomes a hard gate, tighten the classification first (only the
structured codes → Missing; a code-less 404 → Unknown) or the gate will
wrongly block private images.

Follow-up to #187 / #188 (per @djzager's review). Filing to capture the design
so the new condition doesn't stay inert.

Dominant language
Go
Stars
5
Forks
13
Avg merge
3d 7h
Merged PRs (30d)
44

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.