Refactor the image-search logic from cmd/podman/search.go to
libpod/image/search.go and update podman-search and the Varlink API to
use it.
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
When parsing a string name for repo and tag (for images output), we
should be using parsenormalizedname and reference.Canonical to
get the proper output.
Resolves: #2175
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>
we now, by default, only prune dangling images. if --all is passed, we
prune dangling images AND images that do not have an associated containers.
also went ahead and enabled the podman-remote image prune side of things.
Fixes: #2192
Signed-off-by: baude <bbaude@redhat.com>
Finally, these members no longer have any users.
Future users should usually call referenceWithRegistry / normalizedReference,
and work with the returned value, instead of reintroducing these variables.
Similarly, direct uses of unnormalizedRef should be rare (only for cases
where the registry and/or path truly does not matter).
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@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>
This will be used in normalizeTag to work with references instead of strings.
Not used anywhere yet, should not change behavior.
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>
This shortens the code a bit, but most importantly ensures that all pulls from
docker.Transport are processed exactly the same way, and there is only a single
store.ParseStoreReference in the pull code.
It's a bit wasteful to call decompose() in getPullRefPair just after
pullGoalFromPossiblyUnqualifiedName has qualified the name, but on balance
only having exactly one code path seems worth it. Alternatively we could
split getPullRefPairToQualifiedDestination from getPullRefPair.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
CHANGES BEHAVIOR.
This bypasses .assemble, and preserves the original
lack of tag / original digest instead of adding :latest/:none
(still subject to ParseStoreReference normalization).
Using the original digest seems clearly correct; dropping the :latest
suffix from .image strings, and adding /library to docker.io/shortname,
only affects user-visible input; later uses of the return value of
pullImageFrom... use ParseStoreReference, which calls reference.ParseNormalizedNamed
and reference.TagNameOnly, so the image name should be processed
the same way whether it contains a tag, or libray/, or not.
This also allows us to drop the problematic hasShaInInputName heuristic/condition/helper.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
CHANGES BEHAVIOR.
This bypasses .assemble, and preserves the original
lack of tag / original digest instead of adding :latest/:none
(still subject to ParseStoreReference normalization).
Using the original digest seems clearly correct; dropping the :latest
suffix from .image strings only affects user-visible input; later
uses of the return value of pullImageFrom... use ParseStoreReference,
which calls reference.TagNameOnly, so the image name should be processed
the same way whether it contains a tag or not.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
This is the primary goal of decompose()+assemble(), to support
qualifying an image name.
Does not have any users yet, so does not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
CHANGES BEHAVIOR.
If the name is qualified, instead of decomposing it into components and
re-assembling, just use the input name unmodified:
- For name:tag values, .assemble() just recreates the input.
- For untagged values, .assemble() adds ":latest"; we keep
the input as is, but both docker.ParseReference and storage.Transport.ParseStoreReference
use reference.TagNameOnly() already.
- For digested references, .assemble() adds ":none", but
the code was already bypassing .assemble() on that path
already - for the source reference. For the destination,
this replaces a :none destination with a the @digest reference,
as expected.
Note that while decompose() has already parsed the input,
it (intentionally) bypassed the docker.io/library normalization;
therefore we parse the input again (via docker.ParseReference) to ensure
that the reference is normalized.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Both imageParts and this function implicitly assume docker.Transport
troughout, so instead of pretending to be flexible about DefaultTransport,
just hard-code docker.ParseReference directly.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
It is only ever set to DefaulTransport, and all of the code
is docker/reference-specific anyway, so there's no point in
making this a variable.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
After inlining assembleWithTransport, we have two branches with
the same prepending of decomposedImage.transport; move that out of
the branches.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
imageParts.transport is a constant, and the design of imageParts
is not transport-independent in any sense; we will want to eliminate
the transport member entirely.
As a first step, drop assembleWithTransport and inline an exact
equivalent into all callers.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
We will eventually want to eliminate most members of imageParts
in favor of using the c/image/docker/reference API directly.
For now, just record the reference.Named value, and we will
replace uses of the other members before removing them.
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
when using container runlabel, if a --name is not provided, we must
deduce the container name from the base name of the image to maintain
parity with the atomic cli.
fixed small bug where we split the cmd on " " rather than using fields could
lead to extra spaces in command output.
Signed-off-by: baude <bbaude@redhat.com>
Display the trust policy of the host system. The trust policy is stored in the /etc/containers/policy.json file and defines a scope of registries or repositories.
Signed-off-by: Qi Wang <qiwan@redhat.com>
i.e. actually reflect the environment variable and/or rootless mode
instead of always using the default path.
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>
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>
Allow user to prune unused/unnamed images, the layer images from building,
via podman rmi --prune.
Allow user to prune stopped/exiuted containers via podman rm --prune.
This should resolve#1910
Signed-off-by: baude <bbaude@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>
We were already writing these to our debug logs. But collecting them
and including them in the error message will make it easier for
callers who don't have debugging enabled to figure out what's going
wrong.
Using multierror gives us both pretty formatting (when we print this
for the user) and programmatic access (for any callers that need to
inspect the constituent errors). With this commit and a config like:
$ cat /etc/containers/registries.conf
[registries.search]
registries = ['registry.access.redhat.com', 'quay.io', 'docker.io']
pulling an unqualified missing image looks like:
$ podman pull does-not/exist
Trying to pull registry.access.redhat.com/does-not/exist:latest...Failed
Trying to pull quay.io/does-not/exist:latest...Failed
Trying to pull docker.io/does-not/exist:latest...Failed
error pulling image "does-not/exist": unable to pull does-not/exist: 3 errors occurred:
* Error determining manifest MIME type for docker://registry.access.redhat.com/does-not/exist:latest: Error reading manifest latest in registry.access.redhat.com/does-not/exist: unknown: Not Found
* Error determining manifest MIME type for docker://quay.io/does-not/exist:latest: Error reading manifest latest in quay.io/does-not/exist: unauthorized: access to the requested resource is not authorized
* Error determining manifest MIME type for docker://does-not/exist:latest: Error reading manifest latest in docker.io/does-not/exist: errors:
denied: requested access to the resource is denied
unauthorized: authentication required
A qualified image looks like:
$ podman pull quay.io/does-not/exist
Trying to pull quay.io/does-not/exist...Failed
error pulling image "quay.io/does-not/exist": unable to pull quay.io/does-not/exist: unable to pull image: Error determining manifest MIME type for docker://quay.io/does-not/exist:latest: Error reading manifest latest in quay.io/does-not/exist: unauthorized: access to the requested resource is not authorized
If one of the searched repositories was offline, you'd get a more
useful routing error for that specific registry. For example:
$ cat /etc/hosts
127.0.0.1 quay.io
$ podman pull does-not/exist
Trying to pull registry.access.redhat.com/does-not/exist:latest...Failed
Trying to pull quay.io/does-not/exist:latest...Failed
Trying to pull docker.io/does-not/exist:latest...Failed
error pulling image "does-not/exist": unable to pull does-not/exist: 3 errors occurred:
* Error determining manifest MIME type for docker://registry.access.redhat.com/does-not/exist:latest: Error reading manifest latest in registry.access.redhat.com/does-not/exist: unknown: Not Found
* Error determining manifest MIME type for docker://quay.io/does-not/exist:latest: pinging docker registry returned: Get https://quay.io/v2/: dial tcp 127.0.0.1:443: connect: connection refused
* Error determining manifest MIME type for docker://does-not/exist:latest: Error reading manifest latest in docker.io/does-not/exist: errors:
denied: requested access to the resource is denied
unauthorized: authentication required
This is our first direct dependency on multierror, but we've been
vendoring it for a while now because opencontainers/runtime-tools uses
it for config validation.
Signed-off-by: W. Trevor King <wking@tremily.us>
Closes: #1456
Approved by: rhatdan
Right now, we don't print errors from c/image while trying to
pull images. This prints the errors when log-level=debug is set
so we can debug errors while pulling.
Signed-off-by: Matthew Heon <mheon@redhat.com>
Closes: #1409
Approved by: baude
Currently `podman pull rhel7/rhel-tools` is failing because it
sees rhel7 as a registry. This change will verify that the returned
registry from the parser is actually a registry and not a repo,
if a repo it will return the correct content, and we will pull the image.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
Closes: #1387
Approved by: mtrmac
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
When pulling a fully-qualified image that fails, we should not be talking about
registries/search registries in the the error message as it is not applicable. If
a image that is fq'd and fails to pull, the error should be simplified.
```
$ sudo podman pull this-does-not-exist.example.com/foo
Trying to pull this-does-not-exist.example.com/foo...Failed
error pulling image "this-does-not-exist.example.com/foo": unable to pull this-does-not-exist.example.com/foo: unable to pull image, or you do not have pull access
$
```
Resolves: #1212
Signed-off-by: baude <bbaude@redhat.com>
Closes: #1216
Approved by: mheon
when pulling, we can fail to find an image (i.e. it doesn't exist) or we
can not have authority/access to pull it. the registries don't tell us
one way or another so the error message needs to cover both.
Resolves#1194
Signed-off-by: baude <bbaude@redhat.com>
Closes: #1195
Approved by: rhatdan
Again, we only needed them split for tests; so, integrate them back.
Then drop all remaining references to pullRefName and pullGoalNames,
which are not used for anything.
Should not change behavior
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Closes: #1198
Approved by: mheon
This more or less reverts 9c9401a96c
"Replace getPullRefPair with getPullRefName"; now that tests don't require
us to use pullRefName, move creation of storage references deeper into the
calls stack to reduce string use.
ir.getSinglePullRefNameGoal is accordingly updated to ir.getSinglePullRefPairGoal,
and we need to add a ~duplicate singlePullRefPairGoal; that duplication
of singlePullRefNameGoal will soon be resolved by dropping singlePullRefNameGoal.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Closes: #1198
Approved by: mheon
Now that we don't need a separate pullGoalNamesFromImageReference for
running tests, inline it back.
This forces us to add some glue code to getSinglePullRefNameGoal
and to convert between pullGoal and *pullGoal; that is temporary
and will be cleaned up soon.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Closes: #1198
Approved by: mheon
This merely wraps the
> return singlePullRefNameGoal(getPullRefName(... reference)), nil
pattern which is used for almost all getPullRefName uses. For now
it seems not really worth it, but it will result in shorter code
(and smaller migration) after we replace getPullRefName with
getPullRefPair, which can fail, again - the pullGoalNamesFromImageReference
will not have to add any error handling.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Closes: #1198
Approved by: mheon
Similarly to pullGoalNamesFromImageReference, use a storage.Store and
test the actually created references; that is more representative,
and clearly shows the impact of further normalization in
storageReference (like defaulting to :latest on NameOnly references).
Only modifies tests, so does not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Closes: #1198
Approved by: mheon
pullGoalNamesFromImageReference has been added only to allow testing without
a storage.Store, because I thought that a storage.Store can only be created
by root.
It turns out that non-root stores, at least good enough for reference
parsing and formatting, are possible (and have existed in c/image/storage
tests), so this creates such a store, and modifies the existing
test to test the created c/image/storage.storageReference values
instead of strings; that is more representative, and clearly shows
the impact of further normalization in storageReference (like
defaulting to :latest on NameOnly references).
Eventually we will want to get rid of pullGoalNames / pullRefName.
Only modifies tests, so does not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Closes: #1198
Approved by: mheon
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
Now that we have a pullGoal, separate determination of the goal from
performing it; we will then introduce another entry point with
a supplied types.ImageReference.
Also remove or correct some misleading comments.
Should not change behavior (but does not add unit tests).
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
... when we even only count them.
This eliminates a rare error case, and saves time re-reading and re-parsing
the input.
(We still compute registryPath redundantly, and it may get out of sync.)
Should not change behavior (but does not add unit tests).
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Closes: #1176
Approved by: rhatdan
Instead of duplicating the hasRegistry logic, just record whether we
did use search or not.
Should not change behavior (but does not add unit tests for all of it).
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Closes: #1176
Approved by: rhatdan
Instead, encode it explicitly in pullGoal.pullAllPairs.
Should not change behavior (but does not add unit tests for
all of it).
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Closes: #1176
Approved by: rhatdan
This is an intermediate version of pullGoal, which exists basically
only for easier testing without containers-storage: (i.e. root access)
in unit tests.
Like pullGoal, we will add more members to make it useful in the future.
RFC: Unlike pullGoal, the return value is *pullGoalNames, because there are
quite a few (return nil, err) cases which would be more difficult to read
when returning a value.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Closes: #1176
Approved by: rhatdan
The eventual goal is to cleanly capture semantics like "pull all images
for DockerArchive" and "did a search through $registries" without
hard-coding it through; and to allow a pullImage variant where
the caller can pass an imageReference directly.
For now, this just wraps []pullRefPair and should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Closes: #1176
Approved by: rhatdan
We are passing the values, don't really need the pointer sharing semantics,
and the structures are small enough, and the arrays short enough,
that we very likely lose on the indirect accesses more than we save on
quicker copying of the slices when extending them. Value semantics
is safer anyway.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Closes: #1176
Approved by: rhatdan
We are passing the values, don't really need the pointer sharing semantics,
and the structures are small enough, and the arrays short enough,
that we very likely lose on the indirect accesses more than we save on
quicker copying of the slices when extending them. Value semantics
is safer anyway.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Closes: #1176
Approved by: rhatdan
All but two cases returning a []*pullRefName only return a single
item. Introduce a helper for that case, which seems not
worth it now, but the return value will get a bit more complex
and introducing the helper now will minimize code changes in future
commits.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Closes: #1176
Approved by: rhatdan
We will introduce helpers for the "single image" case, and having a separate
return statement will make them applicable here.
(Also allows us to reduce the scope of some variables a bit.)
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
They are not used anywhere AFAICS, and the underlying idea
that transport-specific image names are reusable across transports
is very dubious anyway. So, drop them instead of documenting
or fixing them.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Closes: #1176
Approved by: rhatdan
This has no ambition to change the design, just to be clear about
what the design is.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Closes: #1176
Approved by: rhatdan
This avoids another "append an only item to an empty array"
pattern, and will allow us to get rid of the "dest" variable
entirely.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Closes: #1176
Approved by: rhatdan
This should not change behavior, only to make future edits
for an early exit easier to review.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Closes: #1176
Approved by: rhatdan
Almost all paths appended to pullNames exactly once; just construct a
single-element array in place and return it.
That way we can add empty lines as separators, and still come out shorter.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Closes: #1176
Approved by: rhatdan
Because srcRef is created by parsing imgName, both hard-code assumptions
about transport-specific formats of the strings, so that is neither better nor worse;
but we do less explicit parsing.
Should not change behavior for dir:, nor for fully-correct docker-archive:.
docker-archive:, though, also supports docker-archive:path:reference, where
the reference is ignored (with a warning) on read; in such cases the previous
code would use the reference only (not the path), the new code uses both
as the path. Neither works, we just change the failure mode (but
"error opening path:reference" is now more suggestive of the correct usage).
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Closes: #1176
Approved by: rhatdan
This is a bit more specific as to what "ref" or "list" means,
and consistent with refPairsFromPossiblyUnqualifiedName
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Closes: #1176
Approved by: rhatdan
Again, that makes the core logic independent from Runtime == containers-storage,
and easier to test independently.
So, this also adds tests.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Closes: #1176
Approved by: rhatdan
... and use pullRefPairsFromRefNames to convert to the
desired data structure later.
This will make both getPullRefName, and later the bulk of
getPullListFromRef, independent of the storage, and thus much easier to test.
Then add tests for getPullRefName. (Ideally they should be shorter,
e.g. hopefully the .image member can be eliminated.)
Should not change behavior, except that error messages on invalid
dstName will now include the value.
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
On macOS NewImageRuntimeFromOptions fails with chown EPERM because the
"vfs" driver tries to chown its home to root:root 0700; in fact running
as root seems to be a generic requirement. So, skip the tests if not
running as root.
(This could maybe benefit from an extra state, maybe an environment
variable like RUNNING_IN_CI, to make sure the tests are actually
run often enough.)
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Closes: #1115
Approved by: rhatdan
No need to do a separate string search when reference.Parse has already
determined this.
Changes behavior: non-SHA256 digest formats are now recognized as well.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Closes: #1112
Approved by: rhatdan
... which finally makes it very easy to add comprehensive tests; so do that.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Closes: #1112
Approved by: rhatdan
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
One part creates []*pullRefName; the other just trivially converts it
into []*pullRefPair.
Also use much more explicit names to explain the functionality.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Closes: #1112
Approved by: rhatdan
We will use it not only in createNamesToPull, but also in
getPullListFromRef soon.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Closes: #1112
Approved by: rhatdan
"Struct" is meaningless, and we will need the "reference pair"
mentioned to distinguish srcRef+dstRef from srcRef+dstName.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Closes: #1112
Approved by: rhatdan
This consolidates the shaPullName logic into a single place,
(and eliminates the unclear shaPullName member name completely).
The resulting nameToPull will shortly be more generally useful.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Closes: #1112
Approved by: rhatdan
shaPullName is only used internally in createNamesToPull; so, introduce
a nameToPull as a variant of pullStruct which has shaPullName (and does not
have destRef).
Eventually, we want to split pullStruct preparation into easily-testable
store-independent name preparation, and a store-dependent and difficult-to-test
but trivial conversion using StorageTransport.ParseStoreReference.
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
It has no users, and it depends on the incorrect imageParts.hasRegistry.
So, just drop it instead of worrying whether it is OK to change its semantics.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Closes: #1112
Approved by: rhatdan
This also eliminates a duplicate call to reference.Parse() and
removes an impossible erorr path.
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
when there are no registries configured for the system and the user provided
a short image name, we panic'd due a logic bug in recent image pull changes.
Signed-off-by: baude <bbaude@redhat.com>
Closes: #841
Approved by: rhatdan
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
If the user uses the image ID when saving to either docker-archive
or oci-archive, then do not save a reference in the manifest/index.json.
If the user chooses to push without an image reference, i.e <transport>:<path>
it should be valid and succeed.
Signed-off-by: umohnani8 <umohnani@redhat.com>
Closes: #782
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
when pulling from a secure registry that is documented in registries.conf, we
should be able to pull without tls-verify=false
Signed-off-by: baude <bbaude@redhat.com>
Closes: #718
Approved by: rhatdan
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
baude
Valentin Rothberg
Sebastian Jug
Daniel J Walsh
W. Trevor King
Miloslav Trmač
Qi Wang
OpenShift Merge Robot
Matthew Heon
haircommander
umohnani8
Matthew Heon
Giuseppe Scrivano
Jhon Honce