Feature Request: Add checkbox to start a container or pod automatically with the cockpit service.

[DrKittens]

This is a duplicate of #364 which was closed in error as the merge proposed to resolve it does not actually resolve the reported request. it implemented automatic restart not autostart which is fundamentally different in purpose.

To repeat what the requester there requested, cockpit's podman UI is missing an automatic start option natively and/or a way to export/enable a systemd service via the UI natively. For most implementations using podman containers this capability (start a container with the underlying system) is desirable and very likely the default implementation methodology wanted by a casual user. This functionality, in my opinion, is critical to expose in a management UI.

This likely relates to #735 & #1236 as these would provide an avenue to implementing this request but it would be significantly better from a UX point of view if the cockpit UI had a checkbox to flag a container to start automatically skipping the export kube/quadlet config file DIY steps.

Conditions for Successful Implementation:

• : Using only the cockpit UI, an end user can configure a rootful container to be started automatically with the cockpit service
• : Using only the cockpit UI, an end user can configure a rootless container to be started automatically with the cockpit service

A wishlist item that should could be another feature request if this makes it through:

• : Using only the cockpit UI, an end user can configure a start sequence for containers managed by the cockpit UI with simple logic, eg Container A then Container B, then Container C, additionally when Container A and B are Healthy start Container D and once Container D is started stop Container A.

[jelly]

This is a duplicate of #364 which was closed in error as the merge proposed to resolve it does not actually resolve the reported request. it implemented automatic restart not autostart which is fundamentally different in purpose.

That is not entirely true, if you specify podman run --restart=always and enable podman-restart.service the containers will autostart once defautl.target is reached. If it's a user container lingering is required to be enabled.

[DrKittens]

This is a duplicate of #364 which was closed in error as the merge proposed to resolve it does not actually resolve the reported request. it implemented automatic restart not autostart which is fundamentally different in purpose.

That is not entirely true, if you specify podman run --restart=always and enable podman-restart.service the containers will autostart once defautl.target is reached. If it's a user container lingering is required to be enabled.

This does appear to work but does this not make some assumptions for the user?
Most obviously a user cannot take advantage of the autostart capability if they do not also opt into restarting the container every time it fails which may be undesirable?

I'm aware this is a more of a nitpick now, but should these items still not be differentiated?

• I may want a container to restart automatically and start automatically
• I may want a container to not restart on failure but start automatically
• I may want a container to start automatically and restart a single time only if it fails
• I may want a container to start manually but automatically restart every time it fails

I may want multiple combinations of the above which the current configuration does not permit due to the assumption that if i have podman-restart.service enabled and containers set to restart automatically i want all containers to automatically start not just one IE they all take the same non-granular approach.

Tying in restart=always to assume start automatically and start automatically to depend on restart=always makes a limiting assumption for the user and should be separated out.