Support podman pods

[djotaku]

Right now with pods things get messy in Cock-podman when using pods because the containers are just listed in whatever order, not by pod.

Possible Suggestions:

• have pods be a drop-down arrow that then shows the containers in that pod
• have a separate view for pods

[marusak]

I am in favor of having separate Pods view, as we have Containers and Images.
And this view would be similar to Images with listing containers that are in the pod (image lists containers which use that image).
@andreasn WDYT?

[andreasn]

Looking at the Podman CLI, it has two things:
podman pod ps - lists all the pods
podman ps - lists all the containers with Pods as one of the columns.

So we could probably do something similar.

[djotaku]

there's also podman pod ps --ctr-names which shows the pods and the containers in them

[marusak]

So I gave this a bit of though on paper and here are some ideas/notes:

• Two ideas came to me how to list pods:

1. We can have separate panel of Pods as we have images and containers:
   

It would show also Pod column in containers listing.

2. We can have some combined Pods and Containers panel where we would list pods and somehow fit there also containers, that are not in any pods. (Drawn as unassigned system/user containers)
   

In that case we would not need Pod column in containers listing, as it always would be obvious, where it belongs. This however introduces kind of "fake" pods, which is not great.

• We would need a new 'Create Pod' modal, that would be rather simple. And Run Image modal would need to have a new item 'Pod' which would be optional. (And disabled when no pods created with icon and tooltip explaining that there are no pods).
  Alternative for Run Image dialog would be where Image would be dropdown if one would navigate from pod's Add container (this is optional).

• There are also two options, how we would show containers, that belong into a pod.

1. We can just list them and when you click on one of them, it will move the UI to the appropriate container in the Containers panel. (This would work only with 'Alternative 1' of course). We already have such listing in 'Images -> <image> -> Used by'.
2. The listing of containers in pods would be the full show. Meaning that containers could be opened up, having logs and terminal... The UI would not jump, but it would make things more complex (Pods -> <pod> -> Containers -> <container> -> Terminal). This is necessary for 'Alternative 2', possible for alternative 1.

@garrett WDYT?

[garrett]

@marusak Cool! Thanks for sketching all this out! Having the pods view like this might work.

However, it strongly reminds me of zones and the firewall page. Originally, when the firewall page introduced zones, I designed it like this too. We changed the zones to actual groups as a result of some usability studies. We might want to rethink this UI too, to make it more like the newer Firewall Zones implementation (that is: grouped).

Can containers be in multiple pods? Or just one pod?

Are pods used for controlling anything more than networking between grouped containers? Can you start, stop, restart containers together in a pod too? (It does look like you can tell all containers in a pod to perform the same option: http://docs.podman.io/en/latest/pod.html)

Does it make more sense to consider these "groups" in the UI? ("Pod" is jargon most people won't know.) We could have a "create pod group" button (note the "pod" in the name, to help people who know that it's called "pod", but also "group" for everyone else) and also have "ungrouped" containers for those not in a pod.

[garrett]

I've made a mockup based on what we all discussed here and in IRC. It's based on the revised Firewall Zones UI and the mockups I have pending for a rework of the Network page.

We'll need to adjust it with a few (minor) changes, but the main concepts are probably correct:

By default, there's nothing about pods in the UI (except the button to create a pod group) until a pod is created. So, it would generally function like normal for people who do not use pods. But for those who want to group containers into pods, it should help a lot.

[garrett]

I also haven't spec'd out all the menus and dropdowns. We can decide what exactly goes there together. I provided one for the containers. Some of the actions would be similar for the pod groups too, including actions (start/stop/restart) and probably delete or remove, depending what happens with the containers inside of a pod. (Are they deleted as well? Or would the pod be removed and the containers are "free" from a pod?)

Anyway, I hope this provides a good direction! 😁

[marusak]

Thank you @garrett ! This is great, I'll just sum up what we talked about on IRC so it is not forgotten:

• The container rows will not change from the current design. The mockup just keeps it simple, but they should look the same (like that the the first item has 3 rows)
• Filter by owner (and most likely also text filter) should be global on the top of the page as is now. 'Show running/all' for containers is indeed much better in containers panel. 'Show' filter for images probably does not make much sense now.
• 'Create pod' modal exists in my mockups and I think there is not much more we want in that now.
• 'Add Container' modal would have 3 modes (I drawn 2 of them). First would be where image would not be changable and pod would be select (when clicking the play icon on specific image). Second when clicking 'Add container' next to pod would have pod locked down and image would be selectable. Lastly when clicking 'Add container' next to 'Create pod' would have both of those as selects. (Or maybe both of them would be always selects, just that we would preselect in those first two cases).
• There is no 'Move to <pod>'action. There would be just start/stop, restart and delete actions.

Things it misses/are not clear:

• Pod has its own details. Things that cli lists are: ID, name, status, created, # of containers. We could have those on the pod header and we don't need number of containers, users see that. But important thing is also opened ports. We need to show that somehow. Currently design does not count with that.
• Pod also has owner. We don't need 'owner' column then for each container in the pod.