diff options
| author | Matthew Heon <mheon@redhat.com> | 2021-01-12 14:29:27 -0500 |
|---|---|---|
| committer | Matthew Heon <mheon@redhat.com> | 2021-01-14 18:29:28 -0500 |
| commit | 997de2f8e9e5453a99108bde012aa6c41d7323ec (patch) | |
| tree | 499660321cf95f726636fcdd3dd4a8afbb86e2f5 /README.md | |
| parent | 2b7793b6121d336a285fb7b9a7612c221cbf63d2 (diff) | |
| download | podman-997de2f8e9e5453a99108bde012aa6c41d7323ec.tar.gz podman-997de2f8e9e5453a99108bde012aa6c41d7323ec.tar.bz2 podman-997de2f8e9e5453a99108bde012aa6c41d7323ec.zip | |
Initial implementation of renaming containers
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>
Diffstat (limited to 'README.md')
| -rw-r--r-- | README.md | 14 |
1 files changed, 0 insertions, 14 deletions
@@ -71,20 +71,6 @@ A little configuration by an administrator is required before rootless Podman ca See [Skopeo](https://github.com/containers/skopeo/) for those tasks. * Support for the Kubernetes CRI interface for container management. The [CRI-O](https://github.com/cri-o/cri-o) daemon specializes in that. -* Supporting `docker-compose`. We believe that Kubernetes is the defacto - standard for composing Pods and for orchestrating containers, making - Kubernetes YAML a defacto standard file format. Hence, Podman allows the - creation and execution of Pods from a Kubernetes YAML file (see - [podman-play-kube](https://github.com/containers/podman/blob/master/docs/source/markdown/podman-play-kube.1.md)). - Podman can also generate Kubernetes YAML based on a container or Pod (see - [podman-generate-kube](https://github.com/containers/podman/blob/master/docs/source/markdown/podman-generate-kube.1.md)), - which allows for an easy transition from a local development environment - to a production Kubernetes cluster. If Kubernetes does not fit your requirements, - there are other third-party tools that support the docker-compose format such as - [kompose](https://github.com/kubernetes/kompose/) and - [podman-compose](https://github.com/muayyad-alsadi/podman-compose) - that might be appropriate for your environment. This situation may change with - the addition of the REST API. ## OCI Projects Plans |