shouldn't the current directory be the default context for "podman build"?
by Robert P. J. Day
"man podman-build" suggests that the context argument is optional:
SYNOPSIS
podman build [options] [context]
podman image build [options] [context]
...
If no context directory is specified, then Podman will assume
the current working directory as the build context, which
should contain the Containerfile.
but if i have a directory with nothing but a Containerfile, i get:
$ podman build
Error: no context directory specified, and no containerfile specified
$
OTOH, specifying context of current directory:
$ podman build .
STEP 1: FROM alpine:latest
... etc etc ...
thoughts?
rday
1 week, 4 days
image signing
by Hendrik Haddorp
Hi,
is OpenPGP the only supported image signing open supported by podman /
skopeo or are there other options? Using OpenGPG works quite fine for me
so far but in the end we are trying to sign an image using an IBM 4765
crypto card and so far have not figured out how this can play together.
thanks,
Hendrk
3 years, 9 months
Getting Docker Discourse running with Podman
by Philip Rhoades
People,
I can run the discourse image with docker, export the container and
import it as an image into podman.
The script that manages docker discourse containers is:
/var/discourse/launcher
and is attached. It would be good if it were possible to just replace
all the occurrences of "docker" with "podman", fix version numbers etc
and be able to use the script - but can any gurus see dockerisms in the
script that will cause podman gotchas for this idea?
Thanks,
Phil.
--
Philip Rhoades
PO Box 896
Cowra NSW 2794
Australia
E-mail: phil(a)pricom.com.au
3 years, 11 months
Podman API v1.0 Deprecation and Removal Notice
by Tom Sweeney
The Podman v1.0 API relied on the varlink library
(https://github.com/varlink/libvarlink) to handle the underlying
client/server calls from the Podman client to the host where the Podman
service was running. About one year ago, the Podman team was notified
that the varlink library was being deprecated and there would be no
further development and little support for it from the varlink library
team. This led the Podman team to investigate the use of other
client/server technologies and it was decided to develop a RESTful API
for Podman using the native Go libraries.
This new Podman v2.0 RESTful API was released along with Podman v2.0 in
June of 2020 and replaces the Podman API v1.0. As of that time the
Podman v1.0 API for Podman is considered to be deprecated. If there are
issues with the Podman v1.0 API in versions of Podman prior to v2.0 and
those versions are still under support on Red Hat Enterprise Linux
(RHEL), the Podman team will make a best effort to address those
issues. However, no new feature requests for the v1.0 API will be
considered and any problems found with the v1.0 API in Podman v2.0 will
not be addressed.
The new Podman v2.0 RESTful API is split into two halves: one providing
a Docker-compatible API, and a Libpod API providing support for Podman’s
unique features such as pods. The new API works in both a rootful and a
rootless environment. It is a much more flexible solution and Podman
will not have a dependency on another project in order to supply an
API. For more information on the Podman v2.0 RESTful API please see
articles on the podman.io site (https://podman.io/) and also the
documentation for the Podman v2.0 RESTful API
(http://docs.podman.io/en/latest/Reference.html).
Distributions have to support services for the length of their support
agreements. The Podman development team wants to be free to update the
version of Podman during this support cycle. Therefore, we are planning
to drop support for Podman API v1.0 from distributions Red Hats is the
packagers for. The version of Podman, 2.*, which is contained in
Fedora 33, scheduled to be released around Oct 31, 2020, will ship with
no varlink support. We also plan to drop support from the RHEL8.4
release, spring 2021. Other distributions like OpenSUSE have already
disabled varlink support and we have heard that other distributions will
follow suit.
This also serves as a notification that the Podman v1.0 (varlink) API
will be removed from the main GitHub branch of Podman in the near
future. With the release of Podman v2.0 the Podman developers
deprecated the Podman v1.0 API in favor of the new Podman v2.0 RESTful
API. The plan is to remove varlink completely from the Podman v3.0
development branch which will be created some time after September
2020. A 30 day notification of the final removal date will be posted on
the https://podman.iosite and also on the Podman mailing list, along
with social media once it is definitively determined.
If you have any questions or concerns about this notification, please
send a note to the Podman mailing list or create an issue on Podman’s
GitHub (https://github.com/containers/podman/issues) repository.
Note: This notice will be posted to the podman.io site early next week.
4 years, 4 months
New version of podman available
by Daniel Walsh
Mainly bugfix release. Please try this out. Please try this out. We
would like to know if there are any issues, before it gets released to
your favorite distributions.
v2.0.3 <https://github.com/containers/podman/releases/tag/v2.0.3>
@mheon <https://github.com/mheon> mheon <https://github.com/mheon>
released this 16 hours ago · 364 commits
<https://github.com/containers/podman/compare/v2.0.3...master> to master
since this release
Features
* The |podman search| command now allows wildcards in search terms.
* The |podman play kube| command now supports the |IfNotPresent| pull
type.
Changes
* The |--disable-content-trust| flag has been added to Podman for
Docker compatibility. This is a Docker-specific option and has no
effect in Podman; it is provided only to ensure command line
compatibility for scripts (#7034
<https://github.com/containers/podman/issues/7034>).
* Setting a static IP address or MAC address for rootless containers
and pods now causes an error; previously, they were silently ignored.
* The |/sys/dev| folder is now masked in containers to prevent a
potential information leak from the host.
Bugfixes
* Fixed a bug where rootless Podman would select the wrong cgroup
manager on cgroups v1 systems where the user in question had an
active systemd user session (#6982
<https://github.com/containers/podman/issues/6982>).
* Fixed a bug where systems with Apparmor could not run privileged
containers (#6933 <https://github.com/containers/podman/issues/6933>).
* Fixed a bug where ENTRYPOINT and CMD from images were improperly
handled by |podman play kube| (#6995
<https://github.com/containers/podman/issues/6995>).
* Fixed a bug where the |--pids-limit| flag to |podman create| and
|podman run| was parsed incorrectly and was unusable (#6908
<https://github.com/containers/podman/issues/6908>).
* Fixed a bug where the |podman system df| command would error if
untagged images were present (#7015
<https://github.com/containers/podman/issues/7015>).
* Fixed a bug where the |podman images| command would display
incorrect tags if a port number was included in the repository.
* Fixed a bug where Podman did not set a default umask and default
rlimits (#6989 <https://github.com/containers/podman/issues/6989>).
* Fixed a bug where protocols in port mappings were not recognized
unless they were lower-case (#6948
<https://github.com/containers/podman/issues/6948>).
* Fixed a bug where information on pod infra containers was not
included in the output of |podman pod inspect|.
* Fixed a bug where Podman's systemd detection (activated by the
enabled-by-default |--systemd=true| flag) would not flag a container
for systemd mode if systemd was part of the entrypoint, not the
command (#6920 <https://github.com/containers/podman/issues/6920>).
* Fixed a bug where |podman start --attach| was not defaulting
|--sig-proxy| to true (#6928
<https://github.com/containers/podman/issues/6928>).
* Fixed a bug where |podman inspect| would show an incorrect command
(|podman system service|, the command used to start the server) for
containers created by a remote Podman client.
* Fixed a bug where the |podman exec| command with the remote client
would not print output if the |-t| or |-i| flags where not provided.
* Fixed a bug where some variations of the |--format {{ json . }}| to
|podman info| (involving added or removed whitespace) would not be
accepted (#6927 <https://github.com/containers/podman/issues/6927>).
* Fixed a bug where Entrypoint could not be cleared at the command
line (if unset via |--entrypoint=""|, it would be reset to the
image's entrypoint) (#6935
<https://github.com/containers/podman/issues/6935>).
API
* Fixed a bug where the events endpoints (both libpod and compat)
could potentially panic on parsing filters.
* Fixed a bug where the compat Create endpoint for containers did not
properly handle Entrypoint and Command.
* Fixed a bug where the Logs endpoint for containers (both libpod and
compat) would not properly handle client disconnect, resulting in
high CPU usage.
* The type of filters on the compat events endpoint has been adjusted
to match Docker's implementation (#6899
<https://github.com/containers/podman/issues/6899>).
* The idle connection counter now properly handles hijacked connections.
* All endpoints that hijack will now properly print headers per RFC
7230 standards.
Misc
* Updated containers/common to v0.14.6
4 years, 5 months
connecting a container to a bridge network and the host network
by Hendrik Haddorp
Hi,
is it possible to connect a container to a bridge network and also to
the host network?
I would like for my container to have full access to the hosts network
interfaces but still have an IP in the normal bridge network so that
other containers can communicate with it normally.
thanks,
Hendrik
4 years, 5 months
podman --version 2.0.2 is released
by Daniel Walsh
We would appreciate people playing with and testing it. We are trying
to fix as many small bugs as possible, as quick as possible.
Since Podman 2.0 was a major rewrite of the CLI, we are seeing some
issues especially around corner cases.
Thanks for helping out the community.
4 years, 5 months
The Podman repository has been renamed
by Daniel Walsh
The Podman repository has been renamed
By Matt Heon GitHub <https://github.com/mheon>
The Podman <https://podman.io/> repository on Github is moving from
github.com/containers/libpod <https://github.com/containers/libpod> to
github.com/containers/podman <https://github.com/containers/podman>!
Read on to find out why, and how it will affect you.
Three years ago, we created a new Git repository to hold our new
container-management tool and the library it was based on. At the time,
Podman was not named Podman, but |kpod| - a name no one on the team
liked, and one we’d hoped to replace quickly. Given this, we decided to
name the repository after the library we’d written to manage containers
- |libpod|. Four months after that, we made the first public release of
the tool, and with it came a new name - Podman (POD MANager). The rest
is, as they say, history. The Podman team is incredibly grateful for the
success we’ve seen since then, and the way that the community has grown.
...
https://podman.io/blogs/2020/07/07/repo-rename.html
4 years, 5 months
Supported versions of golang for building Podman.
by Daniel Walsh
We are going through a rough transition right now, with us dropping
support for golang 1.12. This is causing some pain in Ubuntu and Debian
communities.
The issues is some of the code we vendor from other projects has added
requirements that only work on golang 1.13 and beyond. Currently the
stable branch of golang is 1.14 and 1.13.
Valentin Rothberg reports to me.
> Good news is that we are lucky: Debian testing and unstable are both
> on Go 1.14 (https://packages.debian.org/search?keywords=golang).
He suggests:
> a policy that our tools (at new release) must be compatible with the
> officially supported versions of Go, which is always the last two
> major/minor versions. In case of Podman 2.0: 1.14 and 1.13. If we can
> commit to that, the community can't really get angry at us; it's
> reasonable to move on once a version hits EOL. However, breaking
> changes are always an annoyance ...
I agree with this suggestion. And think this is the way we should go
forward.
We are also working to make sure we can build on Ununtu LTS.
RHEL and Centos already can use the golang 1.13 compilers.
4 years, 5 months
