CI:IMG Backport VM Images with go 1.13 #7365
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
podman containers using IPv6 were missing the default route, breaking deployments trying to use them. The problem is that the default route was hardcoded to IPv4, this takes into consideration the podman subnet IP family to generate the corresponding default route. Signed-off-by: Antonio Ojea <[email protected]>
Commit 2b6dd3f set the killmode of the podman.service to the systemd default which ultimately lead to the problem that systemd will kill *all* processes inside the unit's cgroup and hence kill all containers whenever the service is stopped. Fix it by setting the type to sdnotify and the killmode to process. `podman system service` will send the necessary notify messages when the NOTIFY_SOCKET is set and unset it right after to prevent the backend and container runtimes from jumping in between and send messages as well. Fixes: containers#7294 Signed-off-by: Valentin Rothberg <[email protected]>
I'm not sure if this is an OS-specific issue, but on CentOS 8, if `path` doesn't exist, this hangs while waiting to read from this socket, even though the socket is closed by the `reexec_in_user_namespace`. Switching to a pipe fixes the problem, and pipes shouldn't be an issue since this is Linux-specific code. Signed-off-by: Jonathan Dieter <[email protected]>
podman save uses named pipe as output path, not directly using /dev/stdout. fix containers#7017 Signed-off-by: Qi Wang <[email protected]> <MH: Corrected imports during cherry-pick> Signed-off-by: Matt Heon <[email protected]>
I used the wrong propagation first time around because I forgot that rprivate is the default propagation. Oops. Switch to rprivate so we're using the default. Signed-off-by: Matthew Heon <[email protected]>
upon image build completion, a new image type event is written for "build". more intricate details, like pulling an image, that might be done by build must be implemented in different vendored packages only after libpod is split from podman. Fixes: containers#7022 Signed-off-by: Brent Baude <[email protected]> <MH: Fixed imports during cherry-pick> Signed-off-by: Matt Heon <[email protected]>
Signed-off-by: zhangguanzhang <[email protected]>
the deepcopy in the remote history code path was throwing an uncaught error on a type mismatch. we now manually do the conversion and fix the type mismatch on the fly. Fixes: containers#7122 Signed-off-by: Brent Baude <[email protected]>
Podman 1.6.2 changed systemd mode auto-detection from commands ending in ``init`` to hard-coded paths ``/sbin/init`` and ``/usr/sbin/init``. This broke FreeIPA container. ``podman run`` and ``podman create`` now activate systemd mode when the command is ``/usr/local/sbin/init``. Fixes: containers#7287 Signed-off-by: Christian Heimes <[email protected]>
Signed-off-by: Christian Heimes <[email protected]>
To sync the behavior between AppArmor and seccomp it is now possible to also specify seccomp profiles for privileged containers. Signed-off-by: Sascha Grunert <[email protected]>
A recent crun change stopped the creation of the container's working directory if it does not exist. This is arguably correct for user-specified directories, to protect against typos; it is definitely not correct for image WORKDIR, where the image author definitely intended for the directory to be used. This makes Podman create the working directory and chown it to container root, if it does not already exist, and only if it was specified by an image, not the user. Signed-off-by: Matthew Heon <[email protected]>
This matches Docker behavior, and seems to make sense - the CMD may have been specific to the original entrypoint and probably does not make sense if it was changed. While we're in here, greatly simplify the logic for populating the SpecGen's Command. We create the full command when making the OCI spec, so the client should not be doing any more than setting it to the Command the user passed in, and completely ignoring ENTRYPOINT. Fixes containers#7115 Signed-off-by: Matthew Heon <[email protected]>
Buildah and podman build can create images without a working dir. FROM fedora WORKDIR /test If you build this image with caching twice, the second time the image will not have a working dir. Similarly if you execute podman run --workdir /foobar fedora It blows up since the workingdir is not created automatically. Finally there was duplicated code for getting the workingdir out of an image, that this PR removes. Signed-off-by: Daniel J Walsh <[email protected]>
Included old error + wrapped Signed-off-by: Parker Van Roy <[email protected]>
Refactor the processing of Repository and Tag fields to default to <none>
when printing via --format flag. Previously, the default format would
print <none> but --format {{.Tag}} would not in some cases.
Fixes containers#7123
Signed-off-by: Jhon Honce <[email protected]>
The ListContainers API previously had a Pod parameter, which determined if pod name was returned (but, notably, not Pod ID, which was returned unconditionally). This was fairly confusing, so we decided to deprecate/remove the parameter and return it unconditionally. To do this without serious performance implications, we need to avoid expensive JSON decodes of pod configuration in the DB. The way our Bolt tables are structured, retrieving name given ID is actually quite cheap, but we did not expose this via the Libpod API. Add a new GetName API to do this. Fixes containers#7214 Signed-off-by: Matthew Heon <[email protected]>
Addresses the multiple "default" userns values found in the podman-run(1) man page: http://docs.podman.io/en/latest/markdown/podman-run.1.html. This in response to: https://bugzilla.redhat.com/show_bug.cgi?id=1860126 which this PR wil fix. Signed-off-by: TomSweeneyRedHat <[email protected]>
Signed-off-by: Matthew Heon <[email protected]>
When we rewrote Podman's pkg/spec, one of the things that was lost was our use of a set of default environment variables, that ensure all containers have at least $PATH and $TERM set. While we're in the process of re-adding it, change it from a variable to a function, so we can ensure the Join function does not overwrite it and corrupt the defaults. Signed-off-by: Matthew Heon <[email protected]>
Signed-off-by: Matthew Heon <[email protected]>
Signed-off-by: Matthew Heon <[email protected]>
Signed-off-by: Matthew Heon <[email protected]>
This reverts commit 66e1626. We are reenabling podman-system-connection. Signed-off-by: Matthew Heon <[email protected]>
Signed-off-by: Jhon Honce <[email protected]>
* Add support to manage multiple connections * Add connection * Remove connection * Rename connection * Set connection as default * Add markdown/man pages * Fix recursion in hack/xref-helpmsgs-manpages Signed-off-by: Jhon Honce <[email protected]> <MH: Fixed build after rebase> Signed-off-by: Matt Heon <[email protected]>
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: cevich The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
cevich
force-pushed
the
v2.0_backport_golang_113
branch
from
fa04771 to
b11b5d4
Compare
cevich
force-pushed
the
v2.0_backport_golang_113
branch
from
b11b5d4 to
5e5ed4c
Compare
|
--force pushed with rebase ontop of #7345 in an attempt to get around ginkgo install golang problems |
cevich
changed the title
|
Sorry, renaming not chowning |
|
Well crap...new images and golang v1.13 doesn't fix the Ubuntu problem: |
cevich
force-pushed
the
v2.0_backport_golang_113
branch
from
5e5ed4c to
b2c40bf
Compare
|
trying #7363 and golang 1.14 now... |
cevich
force-pushed
the
v2.0_backport_golang_113
branch
2 times, most recently
from
6612bc9 to
98febe5
Compare
|
...#7363 and golang 1.13 fails to build/install ginkgo. 😖 |
cevich
force-pushed
the
v2.0_backport_golang_113
branch
from
98febe5 to
05833a1
Compare
|
trying #7345 + golang 1.13... |
|
Wait - you have #7345 passing in CI? Because if that works, I am not really opposed to it... |
Move temporary package updates from `setup_environment.sh` to their proper VM Image build-time scripts. Update all Ubuntu images to use golang 1.13 since all/most containers projects depend upon it. Signed-off-by: Chris Evich <[email protected]>
Signed-off-by: Chris Evich <[email protected]>
cevich
force-pushed
the
v2.0_backport_golang_113
branch
from
05833a1 to
27f60e9
Compare
|
Closing as this does not solve the problem. |
github-actions
bot
added
the
locked - please file new issue/PR
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
A persistent flake occurring only/ever on Ubuntu VMs has thwarted many minutes of debugging time fixing. A hack update of packages was added in but failed to address the issue. Becides always being on Ubuntu, the main flaky-test symptom is the error message:
Error: container_linux.go:349: starting container process caused "error adding seccomp rule for syscall socket: requested action matches default action of filter": OCI runtime error
Since this problem does not seem to be present on the master branch at the time of this commit, attempt to fix the problem by using VM images with newer golang on Ubuntu, as well as updated packages. This is almost purely a speculative fix, as the exact failure mechanism has not been fully debugged.