Skip to content

Commit 27b58c1

Browse files
authored
Merge pull request #811 from cgwalters/logical-more
docs/lbi: Note non-support of "rootless"
2 parents 9d55f15 + aee040c commit 27b58c1

File tree

1 file changed

+26
-1
lines changed

1 file changed

+26
-1
lines changed

docs/src/experimental-logically-bound-images.md

Lines changed: 26 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -40,7 +40,7 @@ COPY ./my-app.image /usr/share/containers/systemd/my-app.image
4040
COPY ./another-app.container /usr/share/containers/systemd/another-app.container
4141

4242
RUN ln -s /usr/share/containers/systemd/my-app.image /usr/lib/bootc/bound-images.d/my-app.image && \
43-
ln -s /usr/share/containers/systemd/my-app.image /usr/lib/bootc/bound-images.d/my-app.image
43+
ln -s /usr/share/containers/systemd/another-app.container /usr/lib/bootc/bound-images.d/another-app.container
4444
```
4545

4646
In the `.container` definition, you should use:
@@ -76,6 +76,31 @@ invocation used by bootc. However, many properties used for container registry i
7676
can be configured via [containers-registries.conf](https://github.com/containers/image/blob/main/docs/containers-registries.conf.5.md)
7777
and apply to all commands operating on that image.
7878

79+
It is not currently supported in general to launch "rootless" containers from system-owned
80+
image stores in general, whether from `/var/lib/containers` or the `/usr/lib/bootc/storage`.
81+
There is no integration between bootc and "rootless" storage today, and none is planned.
82+
Instead, it's recommended to ensure that your "system" or "rootful" containers drop
83+
privileges. More in e.g. <https://github.com/containers/podman/discussions/13728>.
84+
7985
### Distro/OS installer support
8086

8187
At the current time, logically bound images are [not supported by Anaconda](https://github.com/rhinstaller/anaconda/discussions/5197).
88+
89+
## Comparison with default podman systemd units
90+
91+
In the comparison below, the term "floating" will be used for non-logically bound images. These images are often fetched by e.g. [podman-systemd](https://docs.podman.io/en/latest/markdown/podman-systemd.unit.5.html) and may be upgraded, added or removed independently of the host upgrade lifecycle.
92+
93+
### Lifecycle
94+
95+
- **Floating image:** The images are downloaded by the machine the first time it starts (requiring networking typically). Tools such as `podman auto-update` can be used to upgrade them independently of the host.
96+
- **Logically bound image:** The images are referenced by the bootable container and are ensured to be available when the (bootc based) server starts. The image is always upgraded via `bootc upgrade` and appears read-only to other processes (e.g. `podman`).
97+
98+
### Upgrades, rollbacks and garbage collection
99+
100+
- **Floating image:** Managed by the user (`podman auto-update`, `podman image prune`). This can be triggered at anytime independent of the host upgrades or rollbacks, and host upgrades/rollbacks do not affect the set of images.
101+
- **Logically bound image:** Managed exclusively by `bootc` during upgrades. The logically bound images corresponding to rollback deployments will also be retained. `bootc` performs garbage collection of unused images.
102+
103+
### "rootless" container image
104+
105+
- **Floating image:** Supported.
106+
- **Logically bound image:** Not supported (`bootc` cannot be invoked as non-root). Instead, it's recommended to just drop most privileges for launched logically bound containers.

0 commit comments

Comments
 (0)