Hi Reinhard,
Thank you for your concerns, feedback and kind words.
On Tuesday, 2 February 2021 12:04:35 PM AEDT Reinhard Tartler wrote:
> 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.
Fair enough but I think as a user of this technology I'm slightly better
qualified to judge. :)
> I've even reached out to podman upstream to clarify their opinion.
Cool.
> Basically, the workaround to avoid a
> container registry in the nomad-driver-podman package can be characterized
> as "inefficient" at best
Except it is exactly the opposite. I _want_ to have an option to not use
a container registry. I don't want to lose that option as it have serious
advantages.
Your comment makes me suspect that you might have missed my email where
I discuss problems with Docker Registry and especially it is being an
undesirable single point of failure and a redundant critical infrastructure
component.
This is not "inefficient". I _know_ that from experience. We have Docker
Registry used in GitLab CI in customer's projects and I can say with
confidence that minuscule savings from layers de-duplication is trashed
by inefficient and flawed garbage collection (that frequently requires
manual intervention) -- a problem that upstream neglected to address for
years...
Alternative to avoid Docker Registry is more reliable and more simple.
Optimising maintenance is not "inefficient". One can share container images
over HTTP or a network share -- a rationale that rkt once used to demonstrate
that container registry is not required (or not that important).
My experience with container registry taught me that it is not always
desirable.
Depending on size of your base images, there may be not as many common
shared layers that make it worth to de-duplicate (or they may be small
enough).
> 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.
Nomad clearly wishes to have a support for Podman. What's not in scope of
their intentions??
Maintainer of Nomad-driver-Podman cares - he promptly fixed the problem
when he accidentally broke oci-archive support but then Podman broke API...
> I'm a bit surprised that you feel being at the verge of saying "whatever"
> and giving up.
One can only contribute so much effort, you know... My capacity is limited
and I've over-used the efforts I could afford to spend on all this, at the
expense of other matters that now in need of urgent attention...
That makes me appreciate your help even more.
There is a point in time when one might consider cutting the losses and
walking away if it takes too much effort to make things work.
My effort spans over several years. Unfortunately (unlike obsolete rkt)
Podman is not an independent implementation as it requires Docker.
It took me a long while to fix Docker after all its maintainers gave up
on their approach. I was fortunate that Arnaud (current Docker maintainer)
came to help and eventually took over the Docker maintenance. I did not want
to work on Docker but I had to do it because of Podman and with Arnaud
we have invested significant effort to stabilise Docker and its many
dependencies. We can't have Podman without Docker (which is Podman's build
dependency) but at least Podman users can run their Docker-less systems.
> 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?
There is nothing I can do to help upstream with fixing this issue except
to provide feedback on their implementation once they have something to test.
From my prospective the summary of arguments is as follows:
1) More users of docker-composer to prefer the feature over orchestration
Not convincing due to relative weight/benefits of orchestration.
Docker-composer is semi-redundant while orchestration have no alternatives.
IMHO integration with Nomad is more valuable.
2) Release cycle: Podman-3 is better to support throughout the release.
Maybe but interfaces get deprecated a lot. Podman 2 is mature enough and
works well. Upgrading to Podman-3 is certainly not worth doing merely to
remove (lose) Varlink interface and gain support for composer.
Maybe we can have a better upstream support with Podman-3 but who knows?
3) "We want Podman-3"
What matters to me is that some people participating in this discussion
want Podman-3 based on concern #2. It make sense for the long term even
with me holding certain packages until better times - unwanted but small
inconvenience. We can still incorporate Nomad+driver-Podman+Podman_2 into
next release but desire for Podman_3 is a classic dilemma of "better" being
the enemy of "good"...
Reinhard, if you really want Podman-3 in the next Debian release then go
for it and upload to "unstable".
We are yet to build confidence in Nomad-driver-Podman adaptations for new
API... If that not happens in time then so be it and we either won't be
able to run Podman containers under Nomad or would have to install packages
directly from testing/unstable/snapshots. Sigh...
--
Best wishes,
Dmitry Smirnov
GPG key : 4096R/52B6BBD953968D1B
---
Truth — Something somehow discreditable to someone.
-- H. L. Mencken, 1949
---
As of 19 March 2020, COVID-19 is no longer considered to be a high
consequence infectious disease (HCID) in the UK.
-- https://www.gov.uk/guidance/high-consequence-infectious-diseases-hcid
Attachment:
signature.asc
Description: This is a digitally signed message part.