Support a new concept in containers.conf called "modules". A "module"
is a containers.conf file located at a specific directory. More than
one module can be loaded in the specified order, following existing
override semantics.
There are three directories to load modules from:
- $CONFIG_HOME/containers/containers.conf.modules
- /etc/containers/containers.conf.modules
- /usr/share/containers/containers.conf.modules
With CONFIG_HOME pointing to $HOME/.config or, if set, $XDG_CONFIG_HOME.
Absolute paths will be loaded as is, relative paths will be resolved
relative to the three directories above allowing for admin configs
(/etc/) to override system configs (/usr/share/) and user configs
($CONFIG_HOME) to override admin configs.
Pulls in containers/common/pull/1599.
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
now that we have public hypverv fcos artifacts, we can download them
instead of requiring a special build.
Signed-off-by: Brent Baude <bbaude@redhat.com>
[NO NEW TESTS NEEDED]
Vendor latest c/common with changes to add a new Farms
table to containers.conf and update system connection to
add a connection to a farm when --farm is set.
Signed-off-by: Urvashi Mohnani <umohnani@redhat.com>
**podman compose** is a thin wrapper around an external compose provider
such as docker-compose or podman-compose. This means that `podman
compose` is executing another tool that implements the compose
functionality but sets up the environment in a way to let the compose
provider communicate transparently with the local Podman socket. The
specified options as well the command and argument are passed directly
to the compose provider.
The default compose providers are `docker-compose` and `podman-compose`.
If installed, `docker-compose` takes precedence since it is the original
implementation of the Compose specification and is widely used on the
supported platforms (i.e., Linux, Mac OS, Windows).
If you want to change the default behavior or have a custom installation
path for your provider of choice, please change the `compose_provider`
field in `containers.conf(5)`. You may also set the
`PODMAN_COMPOSE_PROVIDER` environment variable.
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
* Use vfkit command line assembly
* Inject ignition file into guest using http over vsock
* Ready notification through use of vsock
[NO NEW TESTS NEEDED]
Signed-off-by: Brent Baude <bbaude@redhat.com>
The --authfile flag has been ignored. Fix that and add a test to make
sure we won't regress another time. Requires a new --tls-verify flag
to actually test the code.
Also bump c/common since common/pull/1538 is required to correctly check
for updates. Note that I had to use the go-mod-edit-replace trick on
c/common as c/buildah would otherwise be moved back to 1.30.
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=2218315
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
Most of the code moved there so if from there and remove it here.
Some extra changes are required here. This is a bit of a mess. The pipe
handling makes this a bit more difficult.
[NO NEW TESTS NEEDED] This is just a rework, existing tests must pass.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
The code was moved to c/common so use that instead. Also add tests for
the new pasta_options config field. However there is one outstanding
problem[1]: pasta rejects most options when set more than once. Thus it is
impossible to overwrite most of them on the cli. If we cannot fix this
in pasta I need to make further changes in c/common to dedup the
options.
[1] https://archives.passt.top/passt-dev/895dae7d-3e61-4ef7-829a-87966ab0bb3a@redhat.com/
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
