tanishqgandhi1908 opened a new pull request, #8546:
URL: https://github.com/apache/texera/pull/8546

   ### What changes were proposed in this PR?
   
   The last piece of #8466: an **Image** dropdown in the create-computing-unit 
dialog.
   
   It lists the images that reached READY and defaults to **Default**, the 
deployment's own image. A user who ignores it sends no image at all, so nothing 
about today's behaviour changes. The dropdown appears only when an 
administrator has curated something, and a tooltip states the two things the 
issue calls out as surprising: the choice is fixed for the unit's lifetime, and 
it affects only that unit.
   
   ![The create dialog with the Image 
field](https://raw.githubusercontent.com/tanishqgandhi1908/texera/assets/cu-image-admin-page/screenshots/picker-1-dialog.png)
   
   ![The dropdown open, listing the ready 
images](https://raw.githubusercontent.com/tanishqgandhi1908/texera/assets/cu-image-admin-page/screenshots/picker-2-options.png)
   
   The chosen image travels as `iid` on the create request, which #8475's 
backend resolves to a pinned digest.
   
   **Curated images are on by default now.** `curatedImages.enabled` moves to 
`true` in `values.yaml` and `kubernetes.conf`. They were off pending the pages 
to manage and to choose them, and both have shipped. A deployment short of node 
disk, or unwilling to offer them, sets it back to false.
   
   The spec that asserted no unit starts while the feature is off goes with it: 
that path now reaches the database, which a unit test has none of, so it could 
no longer be exercised. Its companion now asserts the flag ships on.
   
   ### Any related issues, documentation, discussions?
   
   Closes #8471
   Part of #8466
   
   Stacked on #8470, which supplies the image list this dropdown is built from, 
and on #8475 beneath it.
   
   ### How was this PR tested?
   
   Three new tests, plus the whole path exercised against a real backend.
   
   | Case | What it pins |
   | --- | --- |
   | only ready images | one still being checked is not offered |
   | nothing preselected | the default is the deployment's own image |
   | feature off | the API's 503 leaves the dropdown empty and hidden |
   | chosen image is sent | `iid` reaches the create call |
   | reopening forgets it | the choice is per unit, not sticky |
   
   Two existing specs were updated: both assert the exact argument list to 
`createKubernetesBasedComputingUnit`, which now carries `imageId`, and both now 
assert it is `undefined` when no image is chosen.
   
   ```
   yarn --cwd frontend format:ci     clean
   yarn --cwd frontend run build:ci  0 errors
   yarn --cwd frontend run test:ci   84 passed
   sbt "ComputingUnitManagingService/test" "Config/test" scalafmtCheckAll
                                     173 + 72 passed, clean
   ```
   
   **Against a real stack** (`bin/local-dev.sh up`, computing-unit manager 
talking to minikube), driven through the dialog itself:
   
   ```
   choose "AlphaFold3", Create
     -> pod computing-unit-5 Running
     -> image tagandhi19/texera-cu-alphafold3@sha256:7fc542531d90...
     -> securityContext {runAsNonRoot, runAsUser 1001, drop ALL, no escalation}
   choose "Python ML (sklearn)", Create
     -> image tagandhi19/texera-cu-sklearn@sha256:7e0a8816...
   create against a FAILED image
     -> 403 "Image 7 is not available. It must exist and have passed its check."
   ```
   
   Each pod ran the exact digest recorded for that image, and the unit row 
stored its `imageName`.
   
   ### Was this PR authored or co-authored using generative AI tooling?
   
   Generated-by: Claude Code (Claude Opus 5)
   


-- 
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]

Reply via email to