You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In previous versions, if the .volume file was not found when converting the .container file, the code assumed that the volume name is systemd-<Name of the Volume Unit> and the service name was <Name of the Volume Unit>-volume.service.
As a result, the generated service file has -v systemd-%N:/data in the ExecStart and Requires=%N-volume.service in its [Unit] section.
Setting aside the service name (for which we added support in 5.3.x), the configuration in the issue description worked in previous versions only because the volume name was not set in the .volume file.
If it were something like:
[Volume]
VolumeName=foo
Then, the default resolution of the volume would cause the service to fail because the volume's name would have been foo and not systemd-valkey-demo.
As for the current version, since Quadlet also support setting the name of the generated service, if the key ServiceName is set in the .volume file, the dependency would fail.
To summarize, this configuration worked in previous versions in the sense that it created the service units. But, it might have generated faulty service units.
So, I see three options here:
Break the previous behaviour and not support specifiers - generates correct service files, but breaks previously supported configuration.
Restore the previous behaviour and just assume the names whenever the file is not found - same as just passing it down the systemd but without caring why the files were not found.
Really support specifiers (I don't think %N is the only one we may encounter here). That means resolve the specifier in order to find the real dependencies - best in terms of outcome, but it will require work
BTW the same applies for other dependencies, e.g. Network
Issue Description
With podman 4.9.4 and 5.2.2, I can use a systemd specifier like
%N
to name the volume to use but 5.3.1 rejects thisSteps to reproduce the issue
Describe the results you received
Describe the results you expected
podman info output
Podman in a container
No
Privileged Or Rootless
Rootless
Upstream Latest Release
Yes
Additional environment details
No response
Additional information
No response
The text was updated successfully, but these errors were encountered: