summaryrefslogtreecommitdiff
path: root/docs/source/markdown/podman-pod-create.1.md.in
Commit message (Collapse)AuthorAge
* implement podman updateCharlie Doern2022-09-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | podman update allows users to change the cgroup configuration of an existing container using the already defined resource limits flags from podman create/run. The supported flags in crun are: this command is also now supported in the libpod api via the /libpod/containers/<CID>/update endpoint where the resource limits are passed inthe request body and follow the OCI resource spec format –memory –cpus –cpuset-cpus –cpuset-mems –memory-swap –memory-reservation –cpu-shares –cpu-quota –cpu-period –blkio-weight –cpu-rt-period –cpu-rt-runtime -device-read-bps -device-write-bps -device-read-iops -device-write-iops -memory-swappiness -blkio-weight-device resolves #15067 Signed-off-by: Charlie Doern <cdoern@redhat.com>
* Man pages: refactor common options: --subXidnameEd Santiago2022-08-30
| | | | | | | | | | Whew! This one started off identical everywhere, but the version in podman-run got fixed in #1380, then again in #5192, with no corresponding fixes to any of the other man pages. I went with the podman-run version, with a small change in wording. Signed-off-by: Ed Santiago <santiago@redhat.com>
* Man pages: refactor common options: --gidmapEd Santiago2022-08-24
| | | | | | | | | | | | | | | | Two versions: one for container-related commands, one for pods. The container one is easy: all versions matched, so I made no changes. The pod one is hard to review. I went with the pod-clone version because the pod-create one looks suspicious: it talks in terms of containers, not pods. It's possible that I've got it wrong, and that these two cannot be combined, so please review very carefully. I strongly recommend using hack/markdown-preprocess-review for this one. Signed-off-by: Ed Santiago <santiago@redhat.com>
* Reword --exit-policy optionДилян Палаузов2022-08-14
| | | | | | | | | | | | | Insisting on “DCO” imposes formalities, that serve self-purpose. One cannot assume that the submitter has time or will to read texts about symbolism in software contributions. If the system wants to see the text nrEAUIEUAIe eanuitdnuae EAIUEAUIAIE »ℓ§444.3.72b)°»°ℓ§euaieauuae in each commit, people will write this, or any other text, that the system wants to see. All such text, which presence is mandated by the system, has the same value. Signed-off-by: Дилян Палаузов <git-dpa@aegee.org>
* Man pages: refactor common optionsEd Santiago2022-08-09
| | | | | | Continued. Harder-to-review ones this time. Signed-off-by: Ed Santiago <santiago@redhat.com>
* Refactor common man page options, phase 2Ed Santiago2022-08-09
Followup to #15174. These are the options that are easy(ish) to review: those that have only drifted slightly, and need only minor tweaks to bring back to sanity. For the most part, I went with the text in podman-run because that was cleaned up in #5192 way back in 2020. These diffs primarily consist of using '**' (star star) instead of backticks, plus other formatting and punctuation changes. This PR also adds a README in the options dir, and a new convention: <<container text...|pod text...>> which tries to do the right thing based on whether the man page name includes "-pod-" or not. Since that's kind of hairy code, I've also added a test suite for it. Finally, since this is impossible to review by normal means, I'm temporarily committing hack/markdown-preprocess-review, a script that will diff option-by-option. I will remove it once we finish this cleanup, but be advised that there are still 130+ options left to examine, and some of those are going to be really hard to reunite. Review script usage: simply run it (you need to have 'diffuse' installed). It isn't exactly obvious, but it shouldn't take more than a minute to figure out. The rightmost column (zzz-chosen.md) is the "winner", the actual content that will be used henceforth. You really want an ultrawide screen here. Signed-off-by: Ed Santiago <santiago@redhat.com>