2744 Commits

Author SHA1 Message Date
81e94c9049 Merge pull request #2164 from baude/wehateruntime
podman-remote enable containers
2019-01-16 00:58:11 -08:00
e68f03ae45 Embed runtime struct in super localRuntime
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>
2019-01-15 16:01:25 -06:00
341f91da48 Collaberative podman-remote container exists
Began frameout of container super structs for adapted methods.  This allows for the use
of container exists.

Signed-off-by: baude <bbaude@redhat.com>
2019-01-15 14:50:30 -06:00
1b2f75298d Merge pull request #2161 from baude/remotehistory
add support for podman-remote history
2019-01-15 10:27:36 -08:00
6e47727d8a Merge pull request #2160 from baude/localRuntimerename
Rename localRuntime to runtime in cmd/podman
2019-01-15 09:13:44 -08:00
9a23e285d3 add support for podman-remote history
this adds support to get the history for an image and its
layers using podman-remote.

Signed-off-by: baude <bbaude@redhat.com>
2019-01-15 10:29:24 -06:00
61ca8e5487 Rename localRuntime to runtime in cmd/podman
Signed-off-by: baude <bbaude@redhat.com>
2019-01-15 09:56:50 -06:00
077156d45c Merge pull request #2156 from baude/remotermi
podman remote client -- add rmi
2019-01-15 07:49:55 -08:00
f9f72823ad podman remote integrations tests
add exists and rmi tests back in ...

Signed-off-by: baude <bbaude@redhat.com>
2019-01-15 08:19:26 -06:00
500fb2ca4c Merge pull request #2024 from cevich/fix_git_ci_vm
[skip ci] Hack: Fix get_ci_vm.sh w/ gcloud ssh/scp
2019-01-15 02:28:26 -08:00
1ffb0fc2d1 podman remote client -- add rmi
allow the podman remote client to delete images

Signed-off-by: baude <bbaude@redhat.com>
2019-01-14 15:40:33 -06:00
6301f6a0a9 Merge pull request #2155 from baude/remotetestenable
Run integrations test with remote-client
2019-01-14 13:39:09 -08:00
b30a56c156 Run integrations test with remote-client
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>
2019-01-14 14:51:32 -06:00
30f115a960 Merge pull request #2153 from mheon/update_for_1.0
Update master branch with v1.0 changes from 1.0 branch
2019-01-14 08:17:24 -08:00
6f8e569ae2 Merge pull request #2152 from rhatdan/noexec
Add local storage.conf example to troubleshoot
2019-01-14 07:54:50 -08:00
8ee7eb472d [skip ci] Hack: Fix get_ci_vm.sh w/ gcloud ssh/scp
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>
2019-01-14 10:45:12 -05:00
9ab838524c Update master branch with v1.0 changes from 1.0 branch
Grab release notes, changelog, and version changes so master is
up to date.

Signed-off-by: Matthew Heon <matthew.heon@pm.me>
2019-01-14 10:18:09 -05:00
65e947e111 Add local storage.conf example to troubleshoot
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
2019-01-14 09:53:37 -05:00
264d082106 Merge pull request #2117 from mtrmac/no-imageParts
RFC: Mostly replace imageParts
2019-01-14 01:08:13 -08:00
449116af19 Remove imageParts.{isTagged,registry,name,tag}
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>
2019-01-14 04:07:24 +01:00
797d194050 Clarify comments about isRegistry a bit.
Should not change behavior.

Signed-off-by: Miloslav Trmač <mitr@redhat.com>
2019-01-14 04:07:24 +01:00
ad90c44f8d Use imageParts.unnormalizedRef in GetImageBaseName
... to remove the last user of imageParts.name.

Should not change behavior.

Signed-off-by: Miloslav Trmač <mitr@redhat.com>
2019-01-14 04:07:24 +01:00
fa42f97507 FIXME? Introduce imageParts.suspiciousRefNameTagValuesForSearch
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>
2019-01-14 04:07:24 +01:00
cf40b71614 Use imageParts.referenceWithRegistry in Image.getLocalImage
... to make sure everything uses the same code path.

Should not change behavior.

Signed-off-by: Miloslav Trmač <mitr@redhat.com>
2019-01-14 04:07:23 +01:00
d559365d7a Don't try to look up local images with an explicit :latest suffix
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>
2019-01-14 04:07:23 +01:00
f92c3ce350 Return a reference.Named from normalizedTag
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>
2019-01-14 04:07:23 +01:00
b9c0f2c987 Use reference.TagNameOnly instead of manually adding imageParts.tag in normalizeTag
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>
2019-01-14 04:07:23 +01:00
e060a19c87 Use imageParts.normalizedReference in normalizeTag
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>
2019-01-14 04:07:23 +01:00
1c19d19c6e Add imageParts.normalizedReference()
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>
2019-01-14 04:07:23 +01:00
e58aa74766 Use imageparts.referenceWithRegistry in normalizeTag
... 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>
2019-01-14 04:07:23 +01:00
e5c764ec3c Remove no longer used imageParts.assemble()
Should not change behavior.

Signed-off-by: Miloslav Trmač <mitr@redhat.com>
2019-01-14 04:07:23 +01:00
633501b1b7 Use getPullRefPair / getSinglePullRefPairGoal in pullGoalFromPossiblyUnqualifiedName
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>
2019-01-14 04:07:23 +01:00
81204487db Use imageParts.referenceWithRegistry in pullGoalFromPossiblyUnqualifiedName
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>
2019-01-14 04:07:23 +01:00
2171a39390 Use imageParts.referenceWithRegistry in getPullRefPair
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>
2019-01-14 04:07:23 +01:00
72777b7fee Add imageParts.referenceWithRegistry
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>
2019-01-14 04:07:23 +01:00
ae2a95196e Don't use imageParts.assemble when pulling from a qualified name
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>
2019-01-14 04:07:23 +01:00
035c732ded Reorganize normalizeTag
Move the registry defaulting before tag defaulting.

Should not change behavior.

Signed-off-by: Miloslav Trmač <mitr@redhat.com>
2019-01-14 04:07:23 +01:00
788bc36021 Simplify pullGoalFromPossiblyUnqualifiedName
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>
2019-01-14 04:07:23 +01:00
e9721b757a Remove imageParts.transport
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>
2019-01-14 04:07:23 +01:00
99d2259f8a Simplify pullGoalFromPossiblyUnqualifiedName
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>
2019-01-14 04:07:23 +01:00
3d98c42a3f Inline imageParts.assembleWithTransport into callers
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>
2019-01-14 04:07:23 +01:00
c19294c011 Record the original reference.Named in imageParts
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>
2019-01-14 04:07:22 +01:00
6486e2c41b Drop image.DecomposeString, make image.Parts private imageParts again
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>
2019-01-14 04:06:58 +01:00
a6e668fac5 Don't call image.DecomposeString in imageInListToContainerImage
- It is used to fill Repository(misnamed)/Tag members which have no users;
  so it's completely unclear why this is useful.
- Given the mishandling of tags by imageParts.tag, at the very least
  all new code should primarily use reference.Named (even if
  after a decompose() to internally deal with unqualified names first),
  introducing new uses of original decompose() just reintroduces known
  trouble - so without any provided rationale, reverting seems
  a reasonable default action.
- This drags in all of libpod/image into the "remote client" build,
  which seems undesirable.

Signed-off-by: Miloslav Trmač <mitr@redhat.com>
2019-01-14 03:55:44 +01:00
140ae25c4d Merge pull request #2141 from baude/remotetag
Add darwin support for remote-client
2019-01-13 09:34:33 -08:00
9ada9722ec Merge pull request #2137 from rhatdan/noexec
Add troubleshooting statement for homedirs mounted noexec
2019-01-13 09:16:46 -08:00
f31fdb2219 Merge pull request #2008 from harche/multi-arch
Use multi-arch images in test cases
2019-01-13 06:14:22 -08:00
d252c2ae08 Add troubleshooting statement for homedirs mounted noexec
This fixes https://bugzilla.redhat.com/show_bug.cgi?id=1651228

Users were surprised when they were not able to run a contianer on a noexec homedir.

Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
2019-01-13 06:22:10 -05:00
9493be69b3 Merge pull request #2148 from rhatdan/storage-opt
Set default storage options from mounts.conf file.
2019-01-12 10:08:13 -08:00
a08da37682 Merge pull request #2145 from baude/playcontainerintopod
podman play kube: add containers to pod
2019-01-12 07:20:36 -08:00