This patch adds a new --tls-verify flag to the `podman machine init`
sub command which matches many of our other commands. This allows the
user to optionally control whether TLS verification is enabled or
disabled for download of the machine image.
The default remains to leave the TLS verification decision to the
backend library which defaults to enabling it, this patch just
allows the user to explicitly set it on the CLI.
Fixes: #26517
Signed-off-by: Lewis Roy <lewis@redhat.com>
Starting with [1] we now build and publish the wsl image from the
machine-os repo, as such this special case is no longer needed.
[1] https://github.com/containers/podman-machine-os/pull/142
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
The conditions are always true so they can be removed. And in the case
of exportCheckpoint() the scope means addToTarFiles was overwritten and
thus when it looped over it later the slice was always empty.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
There is one user in the code and one in the tests.
First the test is testing an external function that doesn't seem to make
a lot of sense.
Second when we pull the machine image and renmae doesn't work it would
mean it is on a different disk. That should never happen.
The oci pull is to
~/.local/share/containers/podman/machine/<provider>/cache/<sha>/...
and then it gets moved to
~/.local/share/containers/podman/machine/qemu/cache/<sha>.<extension>
These can under normal circumstances never be on different disk as it
would mean the pulled sha is known ahead of time and then that the blob
path is a mount point which is unrealistic and not something we have to
support.
It also removes three transitive dependencies.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
... to validate that the manifests match expected digests, if any.
Do this everywhere, even where we read local storage which is
mostly trusted, because it is cheap enough and being consistent
makes it less likely for the code to be copied into other
contexts shere the sources are not trusted.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Use specV1.AnnotationTitle instead of hard-coding its value when we go
looking for podman-machine images.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
Cache cleanups only happen if there is a cache miss, and we need to pull a new image
For quay.io/podman/machine-os, we remove all old images from the cache dir. This means we will delete any file that exists in the cache dir; this should be safe to do since the machine pull code should be the only thing touching this cache dir. OCI machine images will always have a different manifest, and won’t be updated with the same manifest, so if the version moves on, there isn’t a reason to keep the old version in the cache, it really doesn’t change.
For Fedora (WSL), we use the cache, so we go through the cache dir and remove any old cached images, on a cache miss. We also switch to using ~/.local/share/containers/podman/machine/wsl/cache as the cache dir rather than ~/.local/share/containers/podman/machine/wsl. Both these behaviors existed in v4.9, but are now added back into 5.x.
For generic files pulled from a URL or a non-default OCI image, we shouldn’t actually cache, so we delete the pulled file immediately after creating a machine image. This restores the behavior from v4.9.
For generic files from a local path, the original file will never be cleaned up
Unsure how to test, so:
[NO NEW TESTS NEEDED]
Signed-off-by: Ashley Cui <acui@redhat.com>
This PR adds libkrun support to podman machine. This is an experimental feature and should not be marketed yet. Before we unmark the experimental status on this function, we will need to have full CI support and a full podman point release has pased.
This work relies on the fact that vfkit and libkrun share a reasonably (if not perfectly) same API. The --log-level debug option will not show a GUI screen for boots as krun is not capable of this.
Signed-off-by: Brent Baude <bbaude@redhat.com>
we are having second thoughts about *requiring* a policy.json on podman
machine hosts. we are concerned that we need to work out some more use
cases to be sure we do not make choices now that limit us in the near
term future. for example, should the policy files be the same for
container images and machine images? And should one live on the host
machine and the other live in the machine?
therefore, if a policy.json *is* present in the correct location, we will use and honor it; however, if it does not, we will allow the machine image to be pulled without a policy.
Signed-off-by: Brent Baude <baude@redhat.com>
Co-authored-by: Paul Holzinger <45212748+Luap99@users.noreply.github.com>
Signed-off-by: Brent Baude <bbaude@redhat.com>
Adding the final machine endpoint as quay.io/podman/machine-os in the
Podman code. As a reminder, we decided we would set this in containers
conf once things settle down and this code would then be removed.
Signed-off-by: Brent Baude <bbaude@redhat.com>
When we set a relative path (i.e. ".") it should be resolved next to
binary so we need to get the base dir. If we join it directly like it
did before you get a path like .../podman/policy.json where podman is the
podman executable so it is not a directory and thus could not contain the
policy.json file.
ref #21964
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
As outlined in #21856, it can take a number of seconds until an image
gets pulled. That is because init is hitting the registry first to look
up the image. To improve the UX, add a new line indicating what
happens.
[NO NEW TESTS NEEDED]
Fixes: #21856
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
For podman machine init, deprecate the --image-path option for --image.
--image now accepts the correct image from containers.conf
Also, add the ability to specify an OCI image from the --image flag using the docker:// transport.
Signed-off-by: Ashley Cui <acui@redhat.com>
We used to use ignition to perform any customization required for podman
machine because our input was a generic FCOS image. Now that we are
building our own images, some of this customization can be migrated to
the Containerfile itself and be less of a burden in our code at boot up.
At the time of this PR, the Containerfile can be found at
https://github.com/baude/podman-machine-images/tree/main. It is only
present for a so-called daily image. There is little liklihood that
this would the final location for the Containerfile so consider it a
working version only.
Split WSL and rest apart in the e2e tests so we no longer ppull the
generic FCOS image for testing.
Note: the change to the pull image name is so PRs are not immediately
broken that are already in the queue.
[NO NEW TESTS REQUIRED]
Signed-off-by: Brent Baude <bbaude@redhat.com>
If we hit an error here, it will be really useful to know
- That we're trying to fetch a container image
- Which image we're trying to fetch
[NO NEW TESTS NEEDED]
Signed-off-by: Colin Walters <walters@verbum.org>
So that this file can be inculded in our windows/macos packages and also
by other packagers.
Right now the default policy is allow everything but we plan to add
signing in the future.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
The default policy file /etc/containers/policy.json location does not
work on windows and for packages that ship a default.
Now we search for the policy.json in the following overwrite locations:
macos and linux:
- ~/.config/containers/policy.json
- /etc/containers/policy.json
windows:
- %APPDATA%\containers\policy.json
Also it offers an additional DefaultPolicyJSONPath var that should be
overwritten at built time with the path of the file that is shipped by
packagers. Thile file is used when none of the overwrite paths exist.
[NO NEW TESTS NEEDED]
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
given that we are moving to building our own machine images, we have
decided to use zstd compression as it is superior in speed to the
alternatives. as such, this pr adds zstd to our machine code; and also
has to account for dealing with sparseness on darwin; which the default
zstd golang library does not.
[NO NEW TESTS NEEDED]
Signed-off-by: Brent Baude <bbaude@redhat.com>
If users cancel the image download with CTRL-C for example then the
blob dir will stay around. The next time we run the download we should
just start the download again and not complain about the existing
directory.
[NO NEW TESTS NEEDED]
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
This PR fixes a small bug in pulling disk artifacts where the machine os
was accidently being set to GOOS instead of "linux". Also removed the
manifest type verification because it served no purpose.
[NO NEW TESTS NEEDED]
Signed-off-by: Brent Baude <bbaude@redhat.com>
this pr represents a shift in how we download podman machine images.
these images will now be stored in oci registry and will replace the
default method of downloading an image. you can still use a reference
to a disk image as a path or url too with the --image-path switch.
the final registry and location of the images has not been determined;
and will need to be updated in podman as well.
i dont think we need to allow --image-path to accept a registry/image
for the podman 5.0 release. i do think there will be demand for this.
upgrades also need to be plumbed. for example, updating from an oci
registry.
once we make decisions on final image locations/registrties as well as
some behaviors of init and the oci pull, we must update the machine-init
documentation.
Signed-off-by: Brent Baude <bbaude@redhat.com>
Moving from Go module v4 to v5 prepares us for public releases.
Move done using gomove [1] as with the v3 and v4 moves.
[1] https://github.com/KSubedi/gomove
Signed-off-by: Matt Heon <mheon@redhat.com>
The following PR is the leading PR for refactoring podman machine with
the following goals:
* less duplication/more re-use
* common configuration file between providers
* more consistentency in how machines are handled by providers
The goal of this PR is the rough refactor. There are still rough spots
for sure, specifically around the podman socket and pipe. This
implemention is only for Linux. All other providers are still present
but will not compile or work. This is why tests for them have been
temporarily suspended.
The ready socket code is another area that needs to be smoothed over.
Right now, the ready socket code is still in QEMU. Preferably it would
be moved to a generic spot where all three approaches to readiness
socket use can be defined.
It should also be noted:
* all machine related tests pass.
* make validate for Linux passes
* Apple QEMU was largely removed
* More code pruning is possible; will become clearer when other
providers are complete.
the dir pkg/machine/p5 is not permanent. i had to seperate this from
machine initially due to circular import problems. i think when all
providers are done (or nearly done), it can be placed and named
properly.
Signed-off-by: Brent Baude <bbaude@redhat.com>
It makes more sense to key off the hypervisor/provider when pulling
disks from oci registries.
i.e. quay.io/libpod/podman-machine-images:5.0-qemu
Also, now that we are in 5.0-dev, I also removed the overrides always
making the podman version 4.6.
[NO NEW TESTS NEEDED]
Signed-off-by: Brent Baude <bbaude@redhat.com>
In #20538, I was asked to consider refactoring the new OCI pull code
from within the generic machine directory. This is something I had
tried when originally coding it but it became apparent that a much
larger refactor to prevent circular deps was needed. Because I did not
want to pollute the initial PR with that refactor, I asked for the PR to
merge first. This is the refactor that needed to be done.
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>
