tanishqgandhi1908 opened a new issue, #8468: URL: https://github.com/apache/texera/issues/8468
### Task Summary The backend of #8466 : somewhere to keep curated images, an admin-only API to manage them, and a check that an image is one a computing unit can start from. Without that check, a misspelled reference or an image that is not a computing-unit image is only discovered when a user's unit sits in ImagePullBackOff, with no explanation anywhere in Texera. A `cu_image` table, one row per image: the reference as given, the digest it resolved to, a status, and the check's output. An admin-only API to register, refresh, list and remove. Registering normalises the reference — a page address, a bare `owner/name:tag`, and one with the registry spelled out all reduce to the same string — then runs `skopeo inspect` in a job. That reads the manifest and config blob, a few kilobytes, never the layers, so it answers in seconds. The row records `owner/name@sha256:…`, and that is what units are started from. Uniqueness is enforced by the database, not just checked in the service: two administrators registering the same link at the same moment both pass a read-then-write check and produce two rows for one image. A curated image is supplied by an administrator and reviewed by nobody, so units started from one run as a non-root user with no privilege escalation and no capabilities. The deployment's own image is left alone. Done when an admin can register a reference, it reaches READY with a pinned digest, a bad one reaches FAILED with a readable reason, and a unit can be created from a ready image. ### Task Type - [ ] Refactor / Cleanup - [ ] DevOps / Deployment / CI - [ ] Testing / QA - [ ] Documentation - [ ] Performance - [ ] Other -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
