Having a parameter that modifies the provides types.SystemContext
seems rather unexpected and risky to have around - and the only
user of that is actually a no-op, others only provide a nil
SystemContext; so, remove that option and simplify (well, somewhat;
many callers now have extra &types.SystemContext{AuthFilePath}
boilerplate; at least that's consistent with that code carrying
a TODO to create a larger-scope SystemContext).
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Having a parameter that modifies the provides types.SystemContext
seems rather unexpected and risky to have around - and the only
user of that is actually a no-op; so, remove that option and simplify.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
which used to contain more context, but now are just
a pointless copy.
Should not change (test) behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
It is no longer used.
Split the existing tests into MakeXRegistryConfigHeader
and MakeXRegistryAuthHeader variants. For now we don't modify
the implementations at all, to make review simpler; cleanups
will follow.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
... which can be called independently.
For now, there are no new callers, to test that the behavior
has not changed.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
... which can be called independently.
For now, there are no new callers, to test that the behavior
has not changed.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
This shares the code, and makes getConfigCredentials
and getAuthCredentials side-effect free and possibly easier to test.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
... and have GetCredentials pass the values down to
getConfigCredentials and getAuthCredentials.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
It's possibly a bit more expensive, but semantically safer
because it does header normalization.
And we'll regain the cost by not looking up the value repeatedly.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Both have a single caller, so there's no point in looking up
the header value twice.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
In the "no input" case, return a constant instead of
continuing with the decode/convert path, converting empty data.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Don't create a single-element map only for the only caller
to laboriously extract an element of that map; just return
a single entry.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Almost every caller is using it only to wrap an error
in exactly the same way, so move that error context into GetCredentials
and simplify the users.
(The one other caller, build, was even wrapping the error incorrectly
talking about query parameters; so let it use the same text as the others.)
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
... as an end-to-end unit test of the header creation/parsing
code.
Leave the docker.io and docker.io/vendor test cases commented out,
because they are currently failing.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Just a single function that handles all of Header,
headerConfig and headerAuth; we will split that later.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
This gives the service 5 seconds to digest the signal and 5 more seconds
to shutdown. Create a new variable to make bumping the timeout easier
in case we see re-flake in the future.
Fixes: #12167
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=2030599
When you create pod, it shares the UTS namespace with Containers.
Currently the --hostname is not passed to the pod created when
you create a container and pod in the same command.
Also fix error message on supported --share flags
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
An error was observed in another PR while downloading the swagger
binary. The error was relating to the upstream egress quota. Obviously
our downloading it every time for each CI run isn't helping. Fix this
by moving the download into the image-build process, and simply re-use
the already present binary here.
Ref: https://github.com/containers/automation_images/pull/103
Signed-off-by: Chris Evich <cevich@redhat.com>
Issue #11825 suggests that *rootless* Podman can run into situations
where too many inotify fds are open. Indeed, rootless Podman has a
slightly higher usage of inotify watchers than the root counterpart
when using slirp4netns
Make sure to not only close all watchers but to also remove the files
from being watched. Otherwise, the fds only get closed
when the files are removed.
[NO NEW TESTS NEEDED] since we don't have a way to test it.
Fixes: #11825
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
...it's not needed: teardown() already does it. Or, it would,
if it had been updated to deal with the new pause image naming
convention, which I've just done.
Signed-off-by: Ed Santiago <santiago@redhat.com>
Users should be able to override containers entrypoint using
`--entrypoint ""` following works fine for podman but not for podman
remote.
Specgen ignores empty argument for entrypoint so make specgen honor
empty arguments.
Signed-off-by: Aditya Rajan <arajan@redhat.com>
GLOBAL_OPTS haven't been supported for at least two major versions of
Podman. The runlabel code is extremely fragile and I think it should
be rewritten before adding new features.
Fixes: #12436
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
commit ee62711136339c5daf38e38859227d85b06fc32a introduced the
regression.
It was mistakenly removed as part of a cleanup, but this code is
needed by another code path, where we move conmon for the exec session
to the same cgroup used by conmon for the process.
Closes: https://github.com/containers/podman/issues/12535
[NO NEW TESTS NEEDED] it fixes a regression in the CI
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
