Rancher Desktop Design - Images

[rak-phillip]

Images

Images is where a bulk of the proposed changes reside. The goal is to make all the different actions we can take while working with images a little more focused

List Images

List all of the images, similar to how we do today with a few changes:

• Perform bulk actions, like scan, on multiple images
• Extract Image Acquisition as a child route for Images
• Scan results are viewable in as a child route

Image Acquisition

• Pull and Build actions are broken out into two separate tabs
• Output is rendered similar to how it is today

Image Scan Detail

• Output is parsed as table
• Ability to export results, if desired
• Link to CVE can be opened in browser window
• Any item can be expanded to view a description and list of references if they exist

Using the space to share this initial design proposal from the UI group. I've add some quick notes for each section of Rancher Desktop that might change. If you have any questions about anything you see below, please ask and I'll provide some more detail.

Original Discussion #683

Feedback is highly valued and welcome.

[jandubois]

Images

Images is where a bulk of the proposed changes reside. The goal is to make all the different actions we can take while working with images a little more focused

I haven't thought through the "Images" functionality yet. But it is getting more complicated:

If we allow multiple runtimes concurrently (and I think this is what @mattfarina wants to disallow, but I disagree, and want to discuss this further), then we can end up with multiple distinct image repositories.

E.g. we might run Kubernetes with containerd but also run moby for docker-cli access. So we have some images managed by 'containerdand some bymoby. Or even we only use containerd, we may have Kubernetes images in the k8s.ionamespace, and onces created bynerdctlindefault`, and the user may want to treat them separately.

So I don't know how this can be made natural in the UI. Potentially we need an image tab for each of the runtimes, even if they share much of the implementation.

I understand that disallowing multiple runtimes "solves" this problem, but I think there is value in being able to enable e.g. Podman to explore something new while keeping moby/docker working for your current projects. Let's discuss this maybe in person?

Comment copied from #683 (comment)

[rak-phillip]

What I'm hearing is that we need to get ahead of the current state. What we have right now are designs that will hopefully set a foundation for some of our more basic interactions in Rancher Desktop. I agree, let's discuss this in person.