Rework our expectations of how images that are derived from each other
look, so that we don't assume that an image that's derived from a base
image always adds layers relative to that base image.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
Add a context.Context parameter to Image.GetParent(), Image.IsParent(),
Image.GetChildren(), Image.Remove(), and Runtime.PruneImages().
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
add the ability for podman to read and write events to journald instead
of just a logfile. This can be controlled in libpod.conf with the
`events_logger` attribute of `journald` or `file`. The default will be
set to `journald`.
Signed-off-by: baude <bbaude@redhat.com>
when deleting a commited image, the path for deletion has an early exit
and the image remove event was not being triggered.
Signed-off-by: baude <bbaude@redhat.com>
Currently in rootless containers, we end up not using the blob cache.
We also don't store the blob cache based on the users specified graph
storage. This change will cause the cache directory to be stored with
the rest of the containe images.
While doing this patch, I found that we had duplicated GetSystemContext in
two places in libpod. I cleaned this up.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
In lipod, we now log major events that occurr. These events
can be displayed using the `podman events` command. Each
event contains:
* Type (container, image, volume, pod...)
* Status (create, rm, stop, kill, ....)
* Timestamp in RFC3339Nano format
* Name (if applicable)
* Image (if applicable)
The format of the event and the varlink endpoint are to not
be considered stable until cockpit has done its enablement.
Signed-off-by: baude <bbaude@redhat.com>
Add the ability to manually run a container's healthcheck command.
This is only the first phase of implementing the healthcheck.
Subsequent pull requests will deal with the exposing the results and
history of healthchecks as well as the scheduling.
Signed-off-by: baude <bbaude@redhat.com>
To get the more-robust handling from 0f6535cf (libpod/image: Use
ParseNormalizedNamed in RepoDigests, 2019-01-08, #2106) here too.
Signed-off-by: W. Trevor King <wking@tremily.us>
The toolbox project would benefit from a few changes to more closely
resembe the original atomic cli project. Changes made are:
* only pull image for container runlabel if the label exists in the image
* if a container image does not have the desired label, exit with non-zero
Signed-off-by: baude <bbaude@redhat.com>
Image.MatchRepoTag and findImageInRepoTags do some kind of
heuristic search; the motivation and design of both, and how they
should deal with digests, is not obvious to me.
Instead of figuring that out now, just factor it out into a
scary-named method and leave the "tag" value (with its "latest"/"none"
value) alone.
Similarly, the .registry and .name fields should typically not be used;
users should use either hasRegistry or normalized reference types;
so, isolate the difficult-to-understand search code, and computation
of these values, into this new search-specific helper.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
imageruntime.getImage, through ParseStoreReference, already uses
reference.TagNameOnly on the input, so this extra lookup is completely
redundant to the lookup that has already happened.
Should not change behavior, apart from speeding up the code a bit.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Instead of returning a string, return a native value and convert it
into the string in the caller, to make it that small bit more
common to use reference types.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Again, rely on the official API, instead of the suprising "suspiciousTagValueForSearch"
value (set to :latest on untagged images, and :none on digested ones!)
CHANGES BEHAVIOR, but the previous output of normalization of digested values was
not even syntatically valid, so this can't really be worse.
Still, maybe we should refuse to tag with digested references in the first place.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
This is another step to using reference values instead of strings here.
CHANGES BEHAVIOR: docker.io/busybox is now normalized to docker.io/library/busybox.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
... instead of open-coding something similar. Eventually
we will use the reference type further in here.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Now that DecomposeString has no users, make the type private again.
Any new users of it should come with a rationale - and new users
of the "none"/"latest" handling of untagged/digested names that is
currently implemented should have an exceptionaly unusual rationale.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Avoid generating
quay.io/openshift-release-dev/ocp-release@sha256@sha256:239... and
similar when the image name is already digest-based [1]. It's not
clear exactly how we get into this state, but as shown by the unit
tests, the new code handles this case correctly (while the previous
code does not).
[1]: https://github.com/containers/libpod/issues/2086
Signed-off-by: W. Trevor King <wking@tremily.us>
Closes: #2106
Approved by: rhatdan
DockerRegistryOptions.DockerInsecureSkipTLSVerify as an types.OptionalBool
can now represent that value, so forceSecure is redundant.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
DockerRegistryOptions.DockerInsecureSkipTLSVerify as an types.OptionalBool
can now represent that value, so forceSecure is redundant.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Following SystemContext.DockerInsecureSkipTLSVerify, make the
DockerRegistryOne also an OptionalBool, and update callers.
Explicitly document that --tls-verify=true and --tls-verify unset
have different behavior in those commands where the behavior changed
(or where it hasn't changed but the documentation needed updating).
Also make the --tls-verify man page sections a tiny bit more consistent
throughout.
This is a minimal fix, without changing the existing "--tls-verify=true"
paths nor existing manual insecure registry lookups.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Add an exists subcommand to podman container and podman image that allows
users to verify the existence of a container or image by ID or name. The return
code can be 0 (success), 1 (failed to find), or 125 (failed to work with runtime).
Issue #1845
Signed-off-by: baude <bbaude@redhat.com>
Execute the command as described by a container image. The value of the label is processed
into a command by:
1. Ensuring the first argument of the command is podman.
2. Substituting any variables with those defined by the environment or otherwise.
If no label exists in the container image, nothing is done.
podman container runlabel LABEL IMAGE extra_args
Signed-off-by: baude <bbaude@redhat.com>
In cases where the image name is more complex like:
quay/baude/alpine_nginx:latest and is not from the docker
registry, we need to be able to run the image by its shortname
such as baude/alpine_nginx. The same goes when the image is
not from a registry but instead has the localhost repository.
This resolves buildah issue #1034
Signed-off-by: baude <bbaude@redhat.com>
Need to get some small changes into libpod to pull back into buildah
to complete buildah transition.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
Closes: #1270
Approved by: mheon
...and some naming decisions.
This change ensures podman save doesn't incorrectly prepend localhost when saving an image.
Signed-off-by: haircommander <pehunt@redhat.com>
Closes: #1140
Approved by: rhatdan
This is similar to the PushImageToHeuristicDestination RFC.
The goal is to be very explicit about which functions try to heuristically
guess what is the expected format of the string. Not quite "shaming"
the users, but making sure they stand out.
RFC:
- Is this at all acceptable? Desirable?
Should not change behavior (but does not add unit tests).
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Closes: #1176
Approved by: rhatdan
FINALLY, (podman load) can pass through an ImageReference directly from
loadCmd all the way to pullGoalNamesFromImageReference, making sure not
to trigger the docker-like reference parsing heuristics.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Closes: #1176
Approved by: rhatdan
All callers of LoadFromArchive expect the input to be in the
transport:name format, or create it that way. So, pass a
types.ImageReference instead of a string.
That requires us to add an explicit parse step in (podman pull);
in (podman load) we can, instead of pasting strings, create
native objects directly.
Changes the error behavior of (podman pull), we no longer
try heuristically parsing docker-archive:... inputs as
Docker references.
Also changes the string reported by (podman load) if all parsing
attempts fail, to be only the path instead of dir:path. The error
message itself is likely to be the same (from directory.Transport).
(While at it, update a mismatched comment.)
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Closes: #1176
Approved by: rhatdan
Use the parent types.SystemContext data instead.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Closes: #1176
Approved by: rhatdan
Use the parent types.SystemContext data instead.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Closes: #1176
Approved by: rhatdan
Use the parent types.SystemContext data instead.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Closes: #1176
Approved by: rhatdan
All callers of getCopyOptions also call GetSystemContext with the same three parameters;
we will want to simplify this by passing the first SystemContext to getCopyOptions,
which can then inherit this data instead of so many parameters everywhere.
For now, just add a *types.SystemContext parameter without using it.
Should not change behavior (but does not add unit tests).
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Closes: #1176
Approved by: rhatdan
pullImage (now) only uses Image.InputName; it is really used to _create_
an Image object, based on the pull results (as is most visible in the
LoadFromArchive caller), so it should not be a method on it.
This also simplifies a bit the number of different kids of uses of
Image.InputName; still apparently not enough to clearly document
the field, though.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Closes: #1176
Approved by: rhatdan
The goal is to be very explicit about which functions try to heuristically
guess what is the expected format of the string. Not quite "shaming"
the users, but making sure they stand out.
RFC:
- Is this at all acceptable? Desirable?
- varlink ExportImage says "destination must have transport type";
should it be using alltransports.ParseImageReference
+ PushImageToReference, then?
(While touching the call in cmd/podman, also remove a commented-out
older version of the call.)
Should not change behavior (but does not add unit tests).
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Closes: #1176
Approved by: rhatdan
When the string is formatted including a constant transport name,
just call the transport to create or parse a reference explicitly.
This avoids unnecessary string formatting and parsing.
Then drop image.TarballTransport, which has no remaining users.
Should not change behavior (but does not add unit tests).
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Closes: #1176
Approved by: rhatdan
This retains the existing string parsing heuristic for users
who must continue to use it (notably the varlink API - or is
it still subject to change?), but allows callers who can get
precise references to supply them without having to deal
with string formatting.
Should not change behavior (but does not add unit tests).
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Closes: #1176
Approved by: rhatdan
We already have a c/image/docker/reference.Named; no need to
round-trip it through a string. This also eliminates the theoretical
parsing failure, and the unchecked .(reference.Named) cast.
Also add a check for DockerReference() == nil to be extra paranoid,
although that should never happen.
Should not change behavior (but does not add unit tests).
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Closes: #1176
Approved by: rhatdan
(... but keep it in DefaultTransport, which remains irregular.)
This makes DockerTransport consistent with the others, and much more importantly,
allows several instances to do
> imgRef.Transport().Name() == DockerTransport
instead of the current
> strings.HasPrefix(DockerTransport, imgRef.Transport().Name())
, which currently works but is pretty nonsensical (it does not check
the "docker://" prefix against the _full reference_, but it checks
the _transport name_ as a prefix of "docker://", i.e. a transport named
"d" would be accepted.
Should not change behavior, because the only currently existing transport
which has a name that is a prefix of "docker://" is c/image/docker.Transport
(but does not add unit tests).
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Closes: #1176
Approved by: rhatdan
If an image is created from another and it is deleted,
only delete the actual image and not the parent images
if the parent images have names/references.
Signed-off-by: umohnani8 <umohnani@redhat.com>
Closes: #1174
Approved by: mheon
The functionality only depends on Image.InputName, and we will want
to make the only user of this independent of the fairly complex Image type.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Closes: #1112
Approved by: rhatdan
... so that it can be tested without side effects, and add the tests.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Closes: #1112
Approved by: rhatdan
when pulling an image that includes a sha such as:
centos/nginx-112-centos7@sha256:42330f7f29ba1ad67819f4ff3ae2472f62de13a827a74736a5098728462212e7
the final image name in libpod should not contain portions of the sha itself nor the sha
identifier. and like docker, we provide a 'none' tag as well.
this should fix#877
Signed-off-by: baude <bbaude@redhat.com>
Closes: #1085
Approved by: mheon
podman rmi was deleting an image even if it was a parent of
another image. This fix just untags the image instead.
This also fixes podman rmi to remove intermediate images of
an image when the image is removed.
Signed-off-by: umohnani8 <umohnani@redhat.com>
Closes: #1055
Approved by: mheon
if we snip the requirement to use a buildah const in the libpod image library,
we can save something on the order of 85 vendored files in consumers of the
the library.
Signed-off-by: baude <bbaude@redhat.com>
Closes: #1054
Approved by: mheon
If the intermediate image exists in the store, podman history
will show the IDs of the intermediate image of each layer.
Signed-off-by: umohnani8 <umohnani@redhat.com>
Closes: #982
Approved by: mheon
The docker-archive tar files can have multiple tags for the same
image stored in it. Load pulls all the tags found in the archive
when loading a tar file. Save can oush multiple tags of the same
image to a tar archive.
Signed-off-by: umohnani8 <umohnani@redhat.com>
Closes: #819
Approved by: rhatdan
Like podman pull, when you push an image, podman should check
if the registry is listed as insecure and if so, it should
--tls-verify=false unless the user overrides this.
Signed-off-by: baude <bbaude@redhat.com>
Closes: #738
Approved by: mheon
Vendor in buildah and use as much of commit and bug as possible for podman
build and commit.
Resolves#586
Signed-off-by: baude <bbaude@redhat.com>
Closes: #681
Approved by: mheon
implement varlink image functions for working with libpod with the exception of a
couple due to incompletions on the libpod side of things (build).
also, created a first pass at a libpodpy package which will stand as a client to
working with libpod's varlink methods using python.
Signed-off-by: baude <bbaude@redhat.com>
Closes: #669
Approved by: baude
When a user pulls an image using a transport, like docker-daemon, we try to lookup
the new image in storage by the input name after the pull. Because the input name
has a transport (different than local storage), that lookup would fail.
Signed-off-by: baude <bbaude@redhat.com>
Closes: #644
Approved by: rhatdan
Made necessary changes to functions to include contex.Context wherever needed
Signed-off-by: umohnani8 <umohnani@redhat.com>
Closes: #640
Approved by: baude
In the case where podman needs to pull an image, if that registry that the image
resides on is known to be insesure (as defined in /etc/containers/registries.conf),
tls-verify should be altered on the fly.
Signed-off-by: baude <bbaude@redhat.com>
Closes: #626
Approved by: mheon
In the case where you have an image local, if the the user runs
podman pull, we should always attempt to pull an updated image.
Added a forceRemote bool to New (image) so we can differentiate
between "pull" or run because the actions differ. Run does not
need to pull the latest -- only run.
Signed-off-by: baude <bbaude@redhat.com>
Closes: #618
Approved by: baude
We should allow users to pass in image ids with the sha256: prefix
for local images.
Resolves: #493
Signed-off-by: baude <bbaude@redhat.com>
Closes: #560
Approved by: baude
When no image is found, display a useful error message. Also, in imageToRef
protect against a nil image being passed.
Resolves: #553
Signed-off-by: baude <bbaude@redhat.com>
Closes: #555
Approved by: mheon
Cull funcs from runtime_img.go which are no longer needed. Also, fix any remaining
spots that use the old image technique.
Signed-off-by: baude <bbaude@redhat.com>
Closes: #532
Approved by: mheon
An image name is really just a tag. When an image has multiple tags, we should be
able to "delete" the one of its tags without harm. In this case, the "delete' is
really a form of Untag (removing the tag from the image).
If an image has multiple tags and the user tries to delete by ID without force, this
should be denied because when you delete by ID there is no distinguishing it like
image tags.
Signed-off-by: baude <bbaude@redhat.com>
Closes: #528
Approved by: mheon
Migrate the podman create and commit subcommandis to leverage the images library. I also had
to migrate the cmd/ portions of run and rmi.
Signed-off-by: baude <bbaude@redhat.com>
Closes: #498
Approved by: mheon
This represents the stage3 implementation for the image library. At this point, we
are moving the image-centric functions to pkg/image including migration of args and
object-oriented references. This is a not a one-for-one migration of funcs and some
funcs will need to continue to reside in runtime_img as they are overly specific to
libpod and probably not useful to others.
Signed-off-by: baude <bbaude@redhat.com>
Closes: #484
Approved by: baude
This is the stage 1 effort for an image library that can be eventually used by buildah and
podman alike. In eventuality, the main goal of the library (package) is to:
* provide a consistent approach to resolving image names in various forms (from users).
* based on the result of the above, provide image methods that in a singular spot but separate from the runtime.
* reduce the cruft and bloat in the current podman runtime.
The goal of stage 1 is to demonstrate fast, accurate image resolution for both local and remote images resulting in
an image object as part of the return.
Signed-off-by: baude <bbaude@redhat.com>
Closes: #463
Approved by: baude
Nalin Dahyabhai
baude
Daniel J Walsh
Qi Wang
Kunal Kushwaha
Sebastian Jug
W. Trevor King
Miloslav Trmač
OpenShift Merge Robot
haircommander
umohnani8
Matthew Heon