Since /etc/machine-id is bind mounted into the toolbox container from
the host operating system, it doesn't make sense to make it mandatory
for images to have that file. Apparently, (some?) Arch Linux images
don't have /etc/machine-id.
Since a missing containerPath for a directory is handled the same way,
there's no reason not to do the same for regular files. It will make
life a bit easier for those creating toolbox images for different
distributions.
https://github.com/containers/toolbox/pull/710
Errors thrown from 'toolbox init-container' are usually not shown to
the user. One has to use 'podman start --attach ...' to see them.
Therefore, it's worth adding the extra bit of information to the error.
https://github.com/containers/toolbox/pull/710
A subsequent commit will handle a missing containerPath when bind
mounting a regular file like /etc/machine-id. Therefore, it's better to
explicitly state that this code is dealing with a directory.
https://github.com/containers/toolbox/pull/710
Not having the corresponding image for UBI toolbox containers show up
in 'toolbox list' is a rough edge. However, the whole UBI feature is
a bit experimental. It's about a gratis RHEL environment getting
created in a jiffy on any host, which is something that hasn't been
done before, and those containers also suffer from various shortcomings
because of the limited package set of UBI.
So it's not that big of a problem if it takes a release or two to
hammer out the details. Especially since it's likely that there will
be a special Toolbox-specific image that's created out of the UBI RPM
repositories, which will likely have the com.github.containers.toolbox
label.
There's also the issue that 0.1.0 needs to be finished, and for that
the the churn needs to be kept down. Changing the labels can very
likely lead to compatibility issues in the future, because of which it
either can't be removed for a while or the wrong images start to get
listed. Some of the older labels have finally been removed, so it's
better not to add more to the list.
In short, this problem will likely fix itself in the coming months, so
it's wise not to create complications trying to rush through a fix.
This reverts commits 1df36591d0 and
e09de9f3e5.
https://github.com/containers/toolbox/issues/753
UBI[0] does not have the recommend Toolbox labels used to track whether
an image/container is truly a toolbox image/container. Thankfully, they
have a number of labels to choose from that we can use to identify the
image. The "com.redhat.component=ubi8-container" seems to be ideal.
The approach of using the UBI8 label introduces one problem though. If
we were to use only one set of labels for both images and containers,
containers created with Podman and not Toolbox from UBI8 would also be
marked as toolbox containers. This is not desired and therefore there
are now two sets of labels. Ones for images where the new label has been
added and other for containers that stays the same.
Since the rewrite of the system test suite[0] we've relied on the Zuul
playbooks for taking care of caching images using Skopeo for increasing
the reliability of the tests (in the past the instability of the Fedora
registry caused problems). This state is problematic if we want to use
the tests in other environments than the Zuul CI. This moves the caching
from Zuul into the system tests.
Currently, Bats does not support officially suite-wide setup and
teardown functions. The solution I chose was to add two new test files
that are executed before and after all tests. This may complicate the
execution of cherry-picked tests but that is not a very common use case
anyway.
The tests are now to some extent capable of adjusting to the host
environment. This is meant in the sense of: I'm running on RHEL, the
"default image" is UBI; I'm running on Fedora, the "default image" is
fedora-toolbox. This mechanism relies on os-release, which is the same
as what Toolbox itself uses.
[0] https://github.com/containers/toolbox/pull/517https://github.com/containers/toolbox/pull/774
The fedora-toolbox:32 image is the first of images in the renamed
toolbox image repository[0]. With the change we can drop the
pull_image_old() function because it was kept only for the old image.
Seems like newer version of ShellCheck checks the validity of variable
names (SC2153). This caused a false positive, so I silenced it.
[0] https://github.com/containers/toolbox/pull/615https://github.com/containers/toolbox/pull/780
The system test refactor[0] replaced the 'run_toolbox' helper function
with 'run toolbox', which is a normal invocation of Toolbox. This makes
it impossible to override Toolbox used during the tests using env var.
[0] https://github.com/containers/toolbox/pull/693
Instead of executing 'podman ps|images' several times in a row, call
them only once and get output with all images/containers. Then, filter
out the JSON using labels and keep images/containers only with matching
labels.
This simplifies the code significantly and cuts down the execution time
of 'toolbox list'. The speed gain is noticeable:
- the system has 5 images and 10 containers
Before patch: ~1.45s
After patch: ~0.85s
- Update "See also" sections
Toolbox does not use Buildah for a considerable time now[0]. We can stop
referencing it in the "See also" sections of the documentation.
In some places mention podman command man pages where they are relevant.
- Add section about toolbox images/containers
Toolbox only supports certain OCI images. These should be documented.
Also, document the change of fedora-toolbox image name.
- Add a section about toolbox container setup
Toolbox containers are specifically configured OCI containers. This
should be documented so that users know what they're using.
- Remove redundant part documentation
The description of what `toolbox init-container` does is already in
toolbox-init-container(1). There's no need to have it in
toolbox-create(1). Instead, replace the text with a hint to visit the
other part of documentation.
- Clarify behaviour of --image option
The fact that Toolbox by default tries to pull from the Fedora
registry[1] should be noted.
- Update synopsis & description of commands
Mention options passed to `podman exec`. Remove redundant paragraph
about container names (is already dealt with in toolbox-create(1)).
There's no need to mention the name of the default container on Fedora
since Toolbox now also supports RHEL.
Mention the default used image on unrecognised systems.
Emphasize the fact that toolboxes are not a fully sandboxed environment.
Update the wording of the description and splits it into a few
subsections.
The description of the --monitor-host was inaccurate and while the
option will go away in the future[2], it is currently in and should be
more documented.
[0] https://github.com/containers/toolbox/pull/160
[1] https://registry.fedoraproject.org
[2] https://github.com/containers/toolbox/pull/617https://github.com/containers/toolbox/pull/512
Since v0.0.91[0] Toolbox throws an error if $PWD is not available in a
toolbox. While this fixes the problem with 'toolbox enter/run' silently
failing to enter/exec in a container, it still requires an action to be
made by the user. I believe it is better to handle such situations more
gracefully by falling back to entering the user's home folder + printing
a warning about doing so.
[0] https://github.com/containers/toolbox/pull/370
Following patches were made:
- Use toolbox for listing containers/images (assumes the existence of
cut and tail)
- Suggest containers for cmd enter
- Don't suggest --container option
- Update global options
- Don't suggest cmd if already specified
The preferred way to provide of a container in commands enter & create
is via an argument.
Since the rewrite in Go, Toolbox provides the --log-level & --log-podman
options. These options deprecate the --verbose & --very-verbose options.
The completion script with this pops already used global options from
the list, handles better cases with different options and suggests log
levels for the --log-level option.
Toolbox can't be used with multiple commands.
The spinner needs to be explicitly stopped before showing the example
'enter' command for using the container. Otherwise, it gets misprinted:
$ toolbox create foo
Creating container foo: / Created container: foo
Enter with: toolbox enter foo
A comment was added to highlight this, since it might not be obvious at
first sight.
Due to such potential quirks, it might be better to keep the spinner
somewhat tightly encapsulated with the code that necessitates it, which
in this case is 'podman create'. For instance, we already need to be
careful to avoid enclosing the pullImage function with a spinner
because it carries it's own.
The code lying between the 'podman pull' and the 'podman create' is so
light that a human user isn't able to discern the absence of a
spinner. So, it seems worth leaning towards ease of understanding and
avoiding potential traps.
This reverts commit 3aaa1d30f1.
https://github.com/containers/toolbox/pull/746
Shell Toolbox has been replaced by the Go implementation a quite while
ago. It is kept in the repository but is no longer actively developed.
There is no need to continue checking it with ShellCheck.
https://github.com/containers/toolbox/pull/733
Call "meson builddir" makes Meson create a build directory called
"builddir". It does not make it build the project. A subsequent call to
"meson compile" or "ninja" needs to be made. This subtle detail causes
a minor (purely visual) discrepancy in the CI output. Fix this for both
unit-test & system-test job definitions.
We now have some Go unit tests[0] and we should use them. By adding a
new test case to Meson, the existing CI job called "shellcheck" has no
longer an accurate name. With this it has been renamed to "unit-test".
Also, the job is now more important and therefore should also be used
for gating.
[0] https://github.com/containers/toolbox/pull/474https://github.com/containers/toolbox/pull/730
The init-container command uses several flags. In the future we'd like
to minimize their number. In order to be able to do that without
breaking systems with older versions of Toolbox, the command can't error
out due to usage of unknown flags.
https://github.com/containers/toolbox/pull/724
Too many appends. Instead, put the required sequence into a single array
and append only the variable parts.
Instead of calling "init-container" with "--verbose", call it rather
with "--log-level debug".
Showing spinner after a lot of work on creating a toolbox is done (even
though not really time consuming) does not make much sense.
When a spinner is started successfully, a stop command is deferred.
There's no need to stop it additionally.
A while ago, 'podman build' stopped supporting COPY with relative
symbolic links [1]. Therefore, these image definitions can't be used
without first temporarily removing the symbolic links, which is
annoying.
The downside is that the copies of README.md now has to be separately
updated, which isn't that big of a hassle compared to the problem that
it fixes.
[1] https://github.com/containers/buildah/issues/1952https://github.com/containers/toolbox/pull/723
When taking ownership of the runtime directory or the initialization
stamp file inside it, it was assumed that the user's GID and UID were
the same. However that might not always be the case.
Note that this commit doesn't use the GID passed from the host to the
toolbox container's entry point to configure the user inside the
container. That is actually more difficult than it sounds. The manual
for useradd(8) says that the group specified by the '--gid' flag must
actually exist.
https://github.com/containers/toolbox/issues/664
Since Fedora 33, `nano` is the default editor[0]. It needs to be
included in the fedora-toolbox image to have the standard Fedora
experience inside the container.
[0] https://fedoraproject.org/wiki/Changes/UseNanoByDefault
CoreOS recently made /boot read-only[0]. This caused an issue with
starting containers because /boot was mounted only with option rslave
but missed the ro option. This caused a permission issue.
This scenario is very similar to the one with /usr on Fedora Silverblue.
The solution for this is to check mount options of the path and check if
it uses the rw option or ro and then add it to the mount options in the
--volume option in 'podman create'.
Fixes: https://github.com/coreos/fedora-coreos-tracker/issues/734
[0] 1de21ffa98https://github.com/containers/toolbox/pull/712
On Fedora Silverblue 33 the output of 'findmnt --noheadings --output
OPTIONS /usr' is:
ro,relatime,seclabel,ssd,space_cache,subvolid=257,subvol=/root
(Fedora uses btrfs as it's default filesystem since version 33[0]). But
when you make the current deployment mutable using 'ostree admin unlock'
the output of the command changes to something like this:
ro,relatime,seclabel,ssd,space_cache,subvolid=257,subvol=/root
rw,relatime,seclabel,lowerdir=usr,upperdir=/var/tmp/ostree-unlock-ovl.JLXHQ0/upper,workdir=/var/tmp/ostree-unlock-ovl.JLXHQ0/work
This causes utils.GetMountOptions to error out preventing a successful
creation of a container with 'toolbox create' when the deployment is
unlocked.
For Toolbox the first line is the more relevant because even though /usr
is technically writeable, it will cease to be after reboot. This is the
current behaviour of the utils.GetMountOptions. Thanks to that I think
it's safe to remove the length check that prevents to create a container
when the current deployment is unlocked.
[0] https://fedoraproject.org/wiki/Changes/BtrfsByDefaulthttps://github.com/containers/toolbox/pull/554
