Update farm build to directly push images to a registry
after all the builds are complete on all the nodes.
A manifest list is then created locally and pushed to
the registry as well.
Signed-off-by: Urvashi Mohnani <umohnani@redhat.com>
The option `farm` which is used to specify the farm to be used, is moved to farm build command from farm command.
closes#20752
Signed-off-by: Chetan Giradkar <cgiradka@redhat.com>
Before this, for some special Podman commands (system reset,
system migrate, system renumber), Podman would create a first
Libpod runtime to do initialization and flag parsing, then stop
that runtime and create an entirely new runtime to perform the
actual task. This is an artifact of the pre-Podman 2.0 days, when
there was almost no indirection between Libpod and the CLI, and
we only used one runtime because we didn't need a second runtime
for flag parsing and basic init.
This system was clunky, and apparently, very buggy. When we
migrated to SQLite, some logic was introduced where we'd select a
different database location based on whether or not Libpod's
StaticDir was manually set - which differed between the first
invocation of Libpod and the second. So we'd get a different
database for some commands (like `system reset`) and they would
not be able to see existing containers, meaning they would not
function properly.
The immediate cause is obviously the SQLite behavior, but I'm
certain there's a lot more baggage hiding behind this multiple
Libpod runtime logic, so let's just refactor it out. It doesn't
make sense, and complicates the code. Instead, make Reset,
Renumber, and Migrate methods of the libpod Runtime. For Reset
and Renumber, we can shut the runtime down afterwards to achieve
the desired effect (no valid runtime after). Then pipe all of
them through the ContainerEngine so cmd/podman can access them.
As part of this, remove the SystemEngine part of pkg/domain. This
was supposed to encompass these "special" commands, but every
command in SystemEngine is actually a ContainerEngine command.
Reset, Renumber, Migrate - they all need a full Libpod and access
to all containers. There's no point to a separate engine if it
just wraps Libpod in the exact same way as ContainerEngine. This
consolidation saves us a bit more code and complexity.
Signed-off-by: Matt Heon <mheon@redhat.com>
<MH: Fixed cherry-pick conflicts for v4.8 branch>
Signed-off-by: Matt Heon <mheon@redhat.com>
It looks like we had some logic for this from #10789 but it does
not appear to have ever worked; we can't pull external containers
out of the DB, so the ContainerRm call failed unconditionally.
Instead, just handle them in Libpod when we're removing images.
We're removing every image, so setting Force when removing images
should get rid of all external containers. It's a little later in
the process than the current (nonfunctional) solution is but I
can't think of a reason why that would be bad.
[NO NEW TESTS NEEDED] We do not currently test `system reset`.
We should probably reevaluate that at some point this year.
Fixes https://issues.redhat.com/browse/RHEL-21261
Signed-off-by: Matt Heon <mheon@redhat.com>
If a user did not set an equal sign in the annotation that old code
would panic when accessing the second element in the slice.
Picked from main 48ab4aec31.
Partially addresses: https://issues.redhat.com/browse/RHEL-21422
[NO NEW TESTS NEEDED]
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Signed-off-by: TomSweeneyRedHat <tsweeney@redhat.com>
Provides Docker API client access, allowing compose to work by default
for HyperV. Basically the HyperV equiv of the work done here by #12916.
[NO NEW TESTS NEEDED]
Signed-off-by: Ashley Cui <acui@redhat.com>
florent found a bug where he used "applehv" as a machine name. it turns out when we use a vmtype name, esp. the active type, it really messes up directory structures for configuration and images alike.
Signed-off-by: Brent Baude <bbaude@redhat.com>
This mostly just inherits the c/common/pkg/auth implementation,
except that AuthFilePath and DockerCompatAuthFilePath can not be set
simultaneously, so don't unnecessarily explicitly set AuthFilePath.
c/common already handles that.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
QEMU usb-host driver which is the one for passthrough, supports two
options for selecting an USB devices in the host to provide it to the
VM:
- Bus and Device number the device is plugged
- Vendor and Product information of the USB devices
https://qemu-project.gitlab.io/qemu/system/devices/usb.html
This commit allows a user to configure podman machine with either of
options, with new --usb command line option for podman machine init.
Examples
podman machine init tosovm4 --usb vendor=13d3,product=5406
podman machine init tosovm3 --usb bus=1,devnum=4 --usb bus=1,devnum=3
This commit also allows a user to change the USBs configured with
--usb command line option for podman machine set.
Note that this commit does not handle host device permissions nor
verify that the USB devices exists.
Signed-off-by: Victor Toso <victortoso@redhat.com>
When using the local client, we should display the compression
algorithm.
If the compression level is set, then show this also.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
we should exit early if a system connection name exists with the name of
the proposed podman machine (i.e. podman-machine-default).
Signed-off-by: Brent Baude <bbaude@redhat.com>
allow podman machine to extract its disk image from an oci registry or
oci-dir locally. for now, the image must be relatively inflexible. it
must have 1 layer. the layer must possess one image. so a dockerfile
like:
FROM scratch
COPY ./myimage.xz /myimage.xz
when using an oci dir, the directory structure must adhere to the
typical directory structure of a an oci image (with one layer).
── blobs
│ └── sha256
│ ├── 53735773573b3853bb1cae16dd21061beb416239ceb78d4ef1f2a0609f7e843b
│ ├── 80577866ec13c041693e17de61444b4696137623803c3d87f92e4f28a1f4e87b
│ └── af57637ac1ab12f833e3cfa886027cc9834a755a437d0e1cf48b5d4778af7a4e
├── index.json
└── oci-layout
in order to identify this new input, you must use a transport/schema to
differentiate from current podman machine init --image-path behavior. we
will support `oci-dir://` and `docker://` as transports.
when using the docker transport, you can only use an empty transport for
input. for example, `podman machine init --image-path docker://`. A
fully quailified image name will be supported in the next iteration.
the transport absent anything means, i want to pull the default fcos
image stored in a registry. podman will determine its current version
and then look for its correlating manifest. in this default use case,
it would look for:
quay.io/libpod/podman-machine-images:<version>
that manifest would then point to specific images that contain the
correct arch and provider disk image. i.e.
quay.io/libpod/podman-machine-images:4.6-qcow2
this PR does not enable something like
docker://quay.io/mycorp/myimage:latest yet.
names, addresses, andf schema/transports are all subject to change. the
plan is to keep this all undocumented until things firm up.
[NO NEW TESTS NEEDED]
Signed-off-by: Brent Baude <bbaude@redhat.com>
Logging to os.Stdout and os.Stderr does not seem to work in
Powershell. I am not entirely certain why.
Logfiles are the best alternative I can think of.
Signed-off-by: Matt Heon <mheon@redhat.com>
Instead of trying to write out own code to do basic process
operations (e.g. checking if a PID is still running in a multi-OS
friendly manner), use shirou/gopsutil, a multi-platform library
that should abstract all the complexity away. Unlike our previous
approach on Windows, this one should actually work.
Signed-off-by: Matt Heon <mheon@redhat.com>
This includes two new hidden commands: a 9p server,
`podman machine server9p`, and a 9p client,
`podman machine client9p` with `server9p` currently only
configured to run on Windows and serve 9p via HyperV vsock, and
`client9p` only configured to run on Linux. The server is run by
`podman machine start` and has the same lifespan as gvproxy
(waits for the gvproxy PID to die before shutting down). The
client is run inside the VM, also by `podman machine start`, and
mounts uses kernel 9p mount code to complete the mount. It's
unfortunately not possible to use mount directly without the
wrapper; we need to set up the vsock and pass it to mount as an
FD.
In theory this can be generalized so that the server can run
anywhere and over almost any transport, but I haven't done this
here as I don't think we have a usecase other than HyperV right
now.
[NO NEW TESTS NEEDED] This requires changes to Podman in the VM,
so we need to wait until a build with this lands in FCOS to test.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
Do not error out immediately but collect all errors and report them if
no candidate succeeded. That'll fix#20502 and improve the quality of
reported errors.
[NO NEW TESTS NEEDED]
Fixes: #20502
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
All `[]string`s in containers.conf have now been migrated to attributed
string slices which require some adjustments in Buildah and Podman.
[NO NEW TESTS NEEDED]
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
Add podman farm build command that sends out builds to
nodes defined in the farm, builds the images on the farm
nodes, and pulls them back to the local machine to create
a manifest list.
Signed-off-by: Urvashi Mohnani <umohnani@redhat.com>
Updated the error message to suggest user to use --replace option to instruct Podman to replace the existsing external container with a newly created one.
closes#16759
Signed-off-by: Chetan Giradkar <cgiradka@redhat.com>
When people report issues, we often ask for the result of `podman info`.
However, if the problem is the remote connection, it will error out with
no information at all. This PR at least will report client information
before disclosing the connection error. For example on Windows:
> .\bin\windows\podman.exe info
client:
OS: windows/amd64
provider: hyperv
version: 4.8.0-dev
host: null
Satisfies: RUN-1720
Signed-off-by: Brent Baude <bbaude@redhat.com>
As requested in containers/podman/issues/20000, add a `privileged` field
to the containers table in containers.conf. I was hesitant to add such
a field at first (for security reasons) but I understand that such a
field can come in handy when using modules - certain workloads require a
privileged container.
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
print only the new container ID when using --replace instead of the
terminated container ID if it was stopped.
Closes: https://github.com/containers/podman/issues/20185
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
After creating a podman machine, and before starting it, the LastUp value for podman machine ls should display Never. Previously, the LastUp value was the same as creation time. This also changes the LastUp value for inspect to ZeroTime instead of creation time.
Signed-off-by: Ashley Cui <acui@redhat.com>
Add --rdt-class=COS to the create and run command to enable the
assignment of a container to a Class of Service (COS). The COS
represents a part of the cache based on the Cache Allocation Technology
(CAT) feature that is part of Intel's Resource Director Technology
(Intel RDT) feature set. By assigning a container to a COS, all PID's of
the container have only access to the cache space defined for this COS.
The COS has to be pre-configured based on the resctrl kernel driver.
cat_l2 and cat_l3 flags in /proc/cpuinfo represent CAT support for cache
level 2 and 3 respectively.
Signed-off-by: Wolfgang Pross <wolfgang.pross@intel.com>
