Description
Feature/Problem:
One of the missing features on podman is the ability to fully backup and restore a pod, (its containers, volumes networking etc..) So I started meddling with creating two scripts to backup and restore from one compute unit to another (RPi). During this endevor I hit the similar issue as (#882) discusses. When creating a pod, the podman_compose.py that the distro I use
podman-compose --version
podman-compose version: 1.0.6
['podman', '--version', '']
using podman version: 5.2.2
podman-compose version 1.0.6
composes the pod name with the prefix 'pod_'.
ie
# podman pod create --name EdgeX
# podman pod list
POD ID NAME STATUS CREATED INFRA ID # OF CONTAINERS
62b91a43dd22 EdgeX Created 5 seconds ago eb13361f19a1 1
^^^^^
(happiness, exactly as asked for)
# podman image prune -f -a # just clear the decks...
# podman compose --project-name EdgeX --in-pod=true --pod-args="--share net,ipc,uts" up -d
# podman pod list
POD ID NAME STATUS CREATED INFRA ID # OF CONTAINERS
2d0fc7725b7e pod_EdgeX Running 9 hours ago a50058181c2e 14
# ^^^^
(Mmm,.. ok not what I asked for but it'll do)
This is all well and good since it's easy to spot a pod in listing output BUT when it comes to exporting it as a kube, things go a bit awry
# podman generate kube pod_EdgeX | grep -A1 -B2 app:
creationTimestamp: "2025-05-02T10:07:05Z"
labels:
app: podEdgeX
name: podEdgeX
This is apparently down to kubernetes rules around container names needing to follow the DNS hostname constraints, where '_' is forbidden, so it looks like somewhere in the workings a filter is applied to try and assuage the issue without erring out... silently changing the name caused me a LOT of confusion during debugging.
Proposed roadpath forward:
I dug around a fair bit but I cannot find a reason why 'pod_' was used as a prefix, other than possible convenience when listing running containers and pods in list output. Looking at podman_compose.py it really doesn't seem to have any other deeper function, so unless I missed something obvious, this can be changed to either [nothing], "pod-", or some sort of --podname-prefix option as I'm sure there are a plethora of scripts already written out there expecting "pod_" as part of the name. If 'pod_' is to remain as a default prefix it would be helpful for some guidance on how to avoid the kube DNS filter trap in docs.
I realise that with respect to #882 the --kubecompat accepted there is fine and all for getting the pod converted but I then have issues with the json config files referring to "pod_" vs "pod". It would be simpler to just avoid the issue in the first place by dealing with the initial podname prefix rename especially as there is no simple means to rename a pod once created.