> > No it hasn't... :( There is a serious regression:
> > https://github.com/hashicorp/nomad-driver-podman/issues/69
>
> I'm having a hard time considering this a "serious" regression. The problem
> as far as I understand is that while the driver does work fine with the
> new REST interface, it doesn't allow you to upload images in OCI format
> from local disk.
> If you instead chose to have imaged pulled from a (local) image registry,
> the driver would work fine.
Do you have experience operating local container registry??
I have and I can tell that it is not fun, to say the least. Docker registry
leaks disk space because it does not garbage collect some images...
Neither does it like Buildah/Podman's native image format, although it
can be remedied by building images with "export BUILDAH_FORMAT=docker".
IMHO just saving built images to network share is the best, easiest, most
reliable way of deploying local images. It is the best to avoid Docker
registry whenever possible.
Have you considered keeping your NFS share with the OCI images,
but using a registry just for distribution to your cluster?
This way your registry is basically just a cache.
Also, there may be alternatives to the official docker registry
image. For instance, debian salsa offers team-specific container
registries (built-in functionality for gitlab). For self-hosting
solutions, maybe
quay.io might be a better fit. On
for simple evaluation/developer setups as well as high-availability
> Blocking podman 3.0 because of this is something I can't get behind.
> But maybe I'm missing something else here?
I hope my answer above helps to understand the issue...
I can follow your thinking, and I sympathize, but ultimately, I
still think that on the compromise between keeping varlink and podman
at version 2.1, and updating to podman 3.0 and getting docker-compose
functionality, Debian's users are better served by having podman 3.0
in bullseye.