Also update README and ensure we point to v4.0.3 as the latest
release, instead of v3.4.7 (which is newer chronologically but
not by actual version).
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
As the title says. Adds a Podman hello image
to the home page. I ran it on windows, so had to have
a blue screen to honor that!
[NO NEW TESTS NEEDED]
Signed-off-by: tomsweeneyredhat <tsweeney@redhat.com>
There's a significant number of non-IRC users in the bridged rooms,
both Matrix and Discord. So, we should mention those options too.
[NO TESTS NEEDED]
Signed-off-by: Lokesh Mandvekar <lsm5@fedoraproject.org>
Project IRC comms are moving to Libera. Update docs.
Confirmation cookie: libera-ieVeeGahbiaf1einguw1xav6bahquie
Signed-off-by: Ed Santiago <santiago@redhat.com>
Basic theory: We remove the container, but *only from the DB*.
We leave it in c/storage, we leave the lock allocated, we leave
it running (if it is). Then we create an identical container with
an altered name, and add that back to the database. Theoretically
we now have a renamed container.
The advantage of this approach is that it doesn't just apply to
rename - we can use this to make *any* configuration change to a
container that does not alter its container ID.
Potential problems are numerous. This process is *THOROUGHLY*
non-atomic at present - if you `kill -9` Podman mid-rename things
will be in a bad place, for example. Also, we can't rename
containers that can't be removed normally - IE, containers with
dependencies (pod infra containers, for example).
The largest potential improvement will be to move the majority of
the work into the DB, with a `RecreateContainer()` method - that
will add atomicity, and let us remove the container without
worrying about depencies and similar issues.
Potential problems: long-running processes that edit the DB and
may have an older version of the configuration around. Most
notable example is `podman run --rm` - the removal command needed
to be manually edited to avoid this one. This begins to get at
the heart of me not wanting to do this in the first place...
This provides CLI and API implementations for frontend, but no
tunnel implementation. It will be added in a future release (just
held back for time now - we need this in 3.0 and are running low
on time).
This is honestly kind of horrifying, but I think it will work.
Signed-off-by: Matthew Heon <mheon@redhat.com>
The file `varlink_remote_client.md` has been removed in commit:
f62a356515e387b0bbcf1f08b4831d139c2039b7
Remove varlink support from Podman
Signed-off-by: Radostin Stoyanov <rstoyanov@fedoraproject.org>
Switch the libpod references to podman in the CONTRIBUTING.md.
Update the cirrus-ci link so we can get a green build again :)
Signed-off-by: Paul Holzinger <paul.holzinger@web.de>
We no longer have to dance around the fact that the repo is named
"libpod" which simplifies the opening a bit. Also, refresh our
scope section and to-do section a bit.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
Some time ago, we moved the Seccomp policy (and related setup
code) to a place where all our tools could share it [1]. We did
not, however, remove the in-repo seccomp.json file. Over the last
year or so, the in-repo seccomp policy has become progressively
more and more outdated, with no effort made to maintain it
(because what sense is there in keeping a duplicate?). Today, a
friend came to me and asked if a Podman container could access
keyctl, assuming it could not because he was reading the outdated
Seccomp policy which does not allow it. Since it's becoming clear
that this file is doing no good and actively causing confusion,
let's just drop it.
[1] https://github.com/seccomp/containers-golang
Signed-off-by: Matthew Heon <mheon@redhat.com>
