This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 1270641 - [DOCS] [7.2] [Feature] Document External Registries and availability of Pause Container in Kubernetes
[DOCS] [7.2] [Feature] Document External Registries and availability of Pause...
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: doc-RHEL-Atomic (Show other bugs)
Unspecified Unspecified
high Severity medium
: rc
: 7.2
Assigned To: Thien-Thi Nguyen
Vikram Goyal
Vikram Goyal
: Documentation
Depends On:
  Show dependency treegraph
Reported: 2015-10-11 23:49 EDT by Vikram Goyal
Modified: 2016-08-04 21:27 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-11-19 19:17:28 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Vikram Goyal 2015-10-11 23:49:13 EDT
Although there is nothing to document for the pause container [1] itself, there are several things we can document.

We should document:

* The fact that there is a pause container and that it is different from the upstream container. It would be good to let the users know about this and the fact that Kube will auto pull from configured registries with default settings.

* If a customer disconnects external registries including RH, then they need to pull pause onto the host first before disconnecting the registries. Make this clear in the docs.

Related, and might be a nice sidebar, we should explain about external registries as described here [2].

We should document this in:

* Getting Started Guide for Containers [3].

Comment 2 Thien-Thi Nguyen 2015-11-02 17:40:14 EST
Hi Eric, i'm writing you (per the trello card linked in the description above) to inquire about the "internal pause container".  Here are my questions:

 (a) Aside from the trello card, is there any other tracking of internal pause containers?
 (b) Where can i read the source to the internal pause container?

I figure if i can follow along w/ (a) and ponder some source w/ (b), i won't need to bother you too much more.  What do you think?
Comment 3 Eric Paris 2015-11-02 18:27:21 EST
sdodson can talk about what we put in the container. Upstream calls it 'pause' but we have a new name. Openshift has some other name (and are going to switch), but I think we have settled that openshift, AE, and AH are all transitioning to 'pod-infrastructure'.

The main purpose of this container is to hold open the network namespace for each pod. Every single pod runs 1 (and only 1) 'pause' container. The container can be launched, the networking for that dummy container can me mutated in any way you wish, and then the real containers which need network access can be launched. Thus the real containers won't race with network mutation and will always see a consistent network state. Even if you need to do long slow network mutations to get the infrastructure container correctly hooked to the network.

The upstream 'pause' container does ABSOLUTELY nothing except go to sleep. It is tiny (size is measured in bytes instead of kb). It exists to keep the network namespace open even if all of the container in the pod were to die for some reason.

The Red Hat pod-infrastructure container may grow (may have already grown, sdodson can tell us) to be a bit more. While it provides the same functionality, it just sleeps and hold the network namespace, it may grow to allow you to exec into the container. It may one day (already?) provide utilities which can help you analyze the network, debug the container from the inside, etc.
Comment 4 Scott Dodson 2015-11-02 21:26:58 EST

The source for the openshift3/pod image is at  This is our equivalent of the pause container.


I think there was some decision to be made as to what it was going to be re-named for AEP and Atomic Host, are you saying definitively that this image is to be named 'pod-infrastruce' ? Is that prefixed in any way aep3/pod-infrastructure? Has this change been made in the origin code base, I don't think it has.
Comment 5 Thien-Thi Nguyen 2015-11-10 10:58:01 EST
The concept of a ‘pause’ (or ‘pod-infrastructure’ or whatever it is named) container does not belong in Getting Started with Containers, but rather in Get Started Orchestrating Containers with Kubernetes.  This is because the concept of a "placeholder container" (to keep the networking namespace "reserved") is only valid in the context of multiple containers on a host (i.e., a "pod").  So, i will mention it there, instead.
Comment 6 Thien-Thi Nguyen 2015-11-10 11:06:30 EST
From IRC discussion, it appears that the following are still unclear:
- renaming decision: yes or no?
- new name
- which product sees which name

I'm changing the needinfo as suggested by eparis.
Comment 8 Thien-Thi Nguyen 2015-11-11 17:32:21 EST
Per IRC discussion w/ Chris Negus:
- cnegus to mention the ‘pause’ container in two Kubernetes articles
- tnguyen to do add a ‘docker pull’ synopsis as described above

Merge request for latter part:
Comment 9 Thien-Thi Nguyen 2015-11-15 08:11:47 EST
The ‘pause’ container portion is merged.  The ‘git pull’ part is in peer review.
Moving status to MODIFIED.
Comment 11 Thien-Thi Nguyen 2015-11-15 13:41:46 EST
All changes merged.  Thanks to Chris Negus, Vikram Goyal, and Yoana Ruseva.
Moving status to RELEASE_PENDING.

Note You need to log in before you can comment on or make changes to this bug.