> The fact that as has been mentioned in this thread a) bullseye is around
> the corner b) nomad-driver-podman isn't even in testing right now, c)
> podman itself is a much more popular package than nomad-driver-podman
> (or nomad for that matter), are all very strong points in favor of
> option (2), but are all *on top* of the original point -- again, IMHO.
[...]
Also consider the discouragement factor. Me, maintainer of podman, nomad,
nomad-driver-podman as well as their countless dependency packages,
is at the verge of saying "whatever" and stop caring or even walk away
from the mess since the moment when technology become useless to me.
Too bad I've invested so much time stabilising it if "release concerns"
require me to break it...
I'll think more about all this.
Thank you for participating in a thoughtful and deliberate manner. I really appreciate it. Please rest assured that I do care about all users of 'testing' and 'unstable' a lot, and that's precisely why I've started this discussion thread. It is important to consider what are the tradeoffs at hand and what's the best interest for our users.
In this case, I'm thinking about users of the upcoming "Debian/stable" release. They are going to use packages from this distribution this year and the years to come. Serving them with nomad as a simple and usable orchestrator surely sounds tempting. The thing is, this thread didn't convince me so far that nomad-driver-podman with the varlink interface provides as much value as I wish it had. I've even reached out to podman upstream to clarify their opinion. Basically, the workaround to avoid a container registry in the nomad-driver-podman package can be characterized as "inefficient" at best as podman would parse each and every layer in every OCI archive on every container start (at least in the 2.x implementation). Also, [1] makes me question whether this use-case is in scope of nomad upstream's intention.
I'd also like to point out that while I agree that we should make every effort to not "break" our users of "testing"/"unstable", the setup remains a QA vehicle. It would be very limiting if we enforced this goal too strictly. Taking it to the extreme, it would prevent the release team from removing packages from 'testing' as even packages with severe bugs like grave security vulnerabilities still provides a lot of value to users that run their setups in an air-gapped environment.
I'm a bit surprised that you feel being at the verge of saying "whatever" and giving up. The basic functionality you are asking for is already present, and just a matter of integrating into the package, a task that you have demonstrated to have significantly more skill than most other developers, me included. The specific setup that you are looking for is currently missing ind podman 3.0, but the workaround Valentin sketched at [2] really doesn't sound that hard to implement. Maybe you can look at it as "almost there" and find motivation in working with upstream on a solution that serves all nomad users rather than throwing in the towel?
--