When addtionalHelperBinariesDir is set, first search that path for helper binaries, then the default locations.
Signed-off-by: Ashley Cui <acui@redhat.com>
The tests are messy and should be turned into table-driven tests but I
do not have time at the moment.
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
Commit 395ba05c44 implemented a POC to allow for changing the behavior
when loading multiple container.conf files in sequence. By default, the
TOML encoder will override existing data/fields with the one specified
in the loaded file. The POC has demonstrated how this behavior can be
changed to append string slices instead of overriding/replacing them
entirely.
This change is the first step of integrating these appendable string
arrays into containers.conf and starts with enabling the `Env`,
`Mounts`, and `Volumes` fields in the `[Containers]` table.
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
Forcing a single upstream default for the init path is bad as some
distro use different install locations for various reasons.
To fix this use the existing helper_binaries_dir field to lookup in all
directories. To keep backwards compatibility we keep using the old
default and both Containers.InitPath and Engine.InitPath. Yes that is
right, somehow we ended up with the same config field under the
containers and engine section and they are both used in podman!
Thus we need to keep supporting both, only the field under the container
section was documented and now recommends the use of helper_binaries_dir.
To make the docs more clear also document what binaries are currently
looked up in helper_binaries_dir.
Note this needs further integration in podman.
Fixes#1110
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Podman should default to sqlite for new installs, however to not break
upgrades we should detect if a boltdb database exists and use that in
such case. Now in order to distinguish between an explicitly set
"sqlite" and "boltdb" and nothing set we use an empty default.
With that podman can know if we really should use the default or if it
was configured for a db explicitly. The actual detection logic must be
implemented in podman as we only know the file locations there.
This commit also drops the unused StateType as this was not used at all.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Let callers (i.e., Podman) decide which defaults to chose. This way,
callers know when to override defaults (i.e., when the values are
empty).
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
1 CPU core typically is not enough for most use cases, so we default to available cores/2 for new machines.
Signed-off-by: Ashley Cui <acui@redhat.com>
It has no external user and should not be exported to avoid any API
misuse; built-in defaults are an implementation detail.
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
Add two new fields Farms and DefaultFarm to the Config
to be used by the new podman buildfarm command.
Signed-off-by: Urvashi Mohnani <umohnani@redhat.com>
We want to allow HPC Customers and others to specify mounts
inside of containers.conf, so that they can have a default
list of mounts into all of thier containers.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
Specify one or more external providers for the compose command. The
first found provider is used for execution. Can be an absolute path or a
(file) name. Relative names are invalid. File names are evaluated via
$PATH look ups.
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
Emit logs on each invocation of the compose command indicating that an
external compose provider is being executed.
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
I added this support to ocijail a while ago but forgot to change the
compiled-in default since I was overriding the value in my
containers.conf.
Signed-off-by: Doug Rabson <dfr@rabson.org>
This fixes a regression in
https://github.com/containers/podman/pull/19241 which quite reasonably
assumed that the default image volume mode from pkg/config was correct.
Signed-off-by: Doug Rabson <dfr@rabson.org>
Add a new field to the network section to allow users to set the default
network program which is used when running rootless containers.
This should be used when you run something like --network private or
--network default as rootless user.
The current default is slirp4netns so we keep that for now. Once I
integrate pasta in the rootless netns then we can consider switching the
default to pasta.
This setting will also be useful then for distros who may not ship pasta
so that they could set it back to slirp if needed.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>