Add option to clone containers #1270

tomasmatus · 2023-04-17T07:43:42Z

Implemets: #363
Adds 'Clone' button to container actions which opens prefilled create container modal.

src/ImageRunModal.jsx

jelly · 2023-04-17T07:55:38Z

src/ImageRunModal.jsx

+            : [];
+
+        const volumes = containerDetail.Mounts.map((mount, index) => {
+            // podman does not expose SELinux labels


I thought it did not, but then I thought I was proven wrong. Is there an issue for this?

hmm right, there's MountLabel. I just need to figure out what it means.

jelly · 2023-04-17T08:01:07Z

src/ImageRunModal.jsx

+            this.setState({
+                dialogWarning: _("This container was not created by cockpit"),
+                dialogWarningDetail: _("Some options may not be copied to the new container."),
+            });


Isn't this something we need to always show? We won't support all options podman has as we won't ever have a feature complete UI.

I think it's okay to not show it when the container is created through cockpit. On the other hand the "check" if it is made by cockpit isn't 100% robust as it only checks whether it was created through commandline or podman API.

martinpitt · 2023-04-18T02:32:08Z

/packit build

tomasmatus · 2023-04-21T09:35:19Z

src/ImageRunModal.jsx

+        const memoryConfigure = containerDetail.HostConfig.Memory > 0;
+        const cpuSharesConfigure = containerDetail.HostConfig.CpuShares > 0;
+        const healthcheck = !!containerDetail.Config.Healthcheck;
+        const healthCheckOnFailureAction = (this.props.version.split(".")) >= [4, 3, 0]


src/ImageRunModal.jsx

KKoukiou

This just creates a new container by copying the configuration from another container. However podman offers the 'clone' API, which does this exact thing internally.
Did we consider using that instead?

garrett · 2023-05-03T16:02:45Z

I discussed this a while back (in 2021) @ #363 (comment):

It basically comes down to this; there are basically three things people want to do:

"Clone" a container, where it's almost the same, but different. The original would still exist. (This is also almost like a template.)
- Mandatory editing with a prefilled version of the create modal dialog, with some values needing to be changed (name) and others should be changed if the container would run at the same time (ports and read/write volumes).
- Duplicates the container, but with changes.
"Edit" a conainer's settings (recreate the same container again, but with a small change, replacing the original container)
- Editing with a prefilled version of the create modal dialog. Changes are all optional.
- Replaces the original container.
"Update" a container by using the exact same settings, but on a newer version of the image. (It might be slightly edited, but usually not.)
- Editing would be optional.
- Pulls new image.
- Replaces the original container.

All three items replicate an existing container's configuration. The differences are all around if it's in addition to and if the configuration changes.

There's an additional 4th option when pods are concerned (now that we have pod support):

"Move" a container into (or out of) a pod group.
- Don't edit.
- Remove the original container.

All of these should probably run the container if the container was running before performing the action. (That is: If the container is running, queue up what we're going to do, perform the action, and make sure it's running after. If it was stopped before, then don't start it.)

However podman offers the 'clone' API, which does this exact thing internally.

Yes, podman container clone makes sense for some of the above, such as moving. If we only support a limited amount of "editing" (as podman clone doesn't let you adjust everything... but it does let you change the name, CPU settings, and other minor things), then it could make sense for cloning too. It doesn't make sense for editing.

As for updating? podman container clone might actually make sense, if I understand it correctly. https://docs.podman.io/en/latest/markdown/podman-container-clone.1.html:

podman container clone [options] container name image
This command takes three arguments: the first being the container ID or name to clone, the second argument in this command can change the name of the clone from the default of $ORIGINAL_NAME-clone, and the third is a new image to use in the cloned container.

The last example is this one:

# podman container clone 2d4d4fca7219b4437e0d74fcdc272c4f031426a6eacd207372691207079551de new_name fedora
Resolved "fedora" as an alias (/etc/containers/registries.conf.d/shortnames.conf)
Trying to pull registry.fedoraproject.org/fedora:latest...
Getting image source signatures
Copying blob c6183d119aa8 done
Copying config e417cd49a8 done
Writing manifest to image destination
Storing signatures
5a9b7851013d326aa4ac4565726765901b3ecc01fcbc0f237bc7fd95588a24f9

...but what if the new name is the same as the old name? And --destroy was given to destroy the original? Would that replace the container with a refreshed version?

Or is there a better way in Podman to recreate a container with the exact same settings but with a new image? There is https://docs.podman.io/en/latest/markdown/podman-auto-update.1.html but it relies on systemd and is supposed to be automatic with a system service based on a timer, instead of a manual update. It does have a way to check if there's a new version with podman auto-update --dry-run --format "{{.Image}} {{.Updated}}" it seems. Perhaps we can do some behind-the-scenes stuff to manually update with podman-auto-update? 🤷

Anyway, back to this PR and @KKoukiou's question about cloning with editing versus podman container clone: I think this PR is trying to answer what I listed above as # 1, whereas podman container clone does not let you edit values outside of the name (which would be mandatory regardless) and some basic settings (such as some CPU and IO related ones).

Adds 'Clone' button to container actions which opens prefilled create container modal.

cockpituous · 2023-06-21T09:51:05Z

src/ImageRunModal.jsx

+        const container = this.props.container;
+        const containerDetail = this.props.containerDetail;
+        const image = this.props.localImages.find(img => img.Id === container.ImageID);
+        const owner = container.isSystem ? 'system' : this.props.user;
