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
