Fix issues with metacopyup when specifying
new usernamespace. Also fixes issues with zfs back end.
Rest of changes come from running make vendor.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
`
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
We clean up the code by eliminating stuttering references when we embed
the runtime struct into localRuntime. Makes for less change in the future
as well.
++ jhonce
Signed-off-by: baude <bbaude@redhat.com>
Add the ability to run the integration (ginkgo) suite using
the remote client.
Only the images_test.go file is run right now; all the rest are
isolated with a // +build !remotelinux. As more content is
developed for the remote client, we can unblock the files and
just block single tests as needed.
Signed-off-by: baude <bbaude@redhat.com>
Previously, using the ssh command directly required obtaining the
external IP of the VM and was then subject to the local configuration.
If the local configuration and/or ssh keys are incorrect, these commands
would fail, preventing automatic setup of the VM.
Fix this by using the gcloud ssh and scp wrappers. Unfortunately rsync
couldn't be made to work in this situation, so use a tarball to transfer
the local repository to the VM. Lastly, execute `setup_environment.sh`
script, then drop the caller into a bash shell sitting in the remote
`$GOSRC` directory.
Signed-off-by: Chris Evich <cevich@redhat.com>
we can define multiple OCI runtimes that can be chosen with
--runtime.
in libpod.conf is possible to specify them with:
[runtimes]
foo = [
"/usr/bin/foo",
"/usr/sbin/foo",
]
bar = [
"/usr/bin/foo",
"/usr/sbin/foo",
]
If the argument to --runtime is an absolute path then it is used
directly without any lookup in the configuration.
Closes: https://github.com/containers/libpod/issues/1750
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
This deprecates the libpod.conf variable of `runtime_path=`, and now has
`runtimes=`, like a map for naming the runtime, preparing for a
`--runtime` flag to `podman run` (i.e. runc, kata, etc.)
Reference: https://github.com/containers/libpod/issues/1750
Signed-off-by: Vincent Batts <vbatts@hashbangbash.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>
Daniel J Walsh
OpenShift Merge Robot
baude
Qi Wang
Chris Evich
Matthew Heon
Giuseppe Scrivano
Vincent Batts
Miloslav Trmač