[CI:DOCS] Man pages: refactor common options: --ipc

[edsantiago]

This is not an easy one to review, sorry.

I went with the version from podman-create. The differences
against podman-run are subtle: apostrophes, whitespace, and
the arg description in the '####' line. Suggestion for review:
run hack/markdown-preprocess-review, then after you finish
with that, cd /tmp/markdown/ipc and use your favorite
two-file diff tool to compare podman-run* against zzz*.

I did not even try to combine the podman-build one; that one
is too different.

Signed-off-by: Ed Santiago [email protected]

more man-page deduplication

[edsantiago]

The podman-build version, for comparison:

podman/docs/source/markdown/podman-build.1.md.in

Lines 323 to 330 in 1bccead

	#### **--ipc**=*how*
	Sets the configuration for IPC namespaces when handling `RUN` instructions.
	The configured value can be "" (the empty string) or "container" to indicate
	that a new IPC namespace should be created, or it can be "host" to indicate
	that the IPC namespace in which `podman` itself is being run should be reused,
	or it can be the path to an IPC namespace which is already in use by
	another process.

[vrothberg]

LGTM

[rhatdan]

/approve
/lgtm
/hold

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: edsantiago, rhatdan, vrothberg

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [edsantiago,rhatdan,vrothberg]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[edsantiago]

EPIPELINEEMPTY. I had a stash of these queued up for submitting one by one, but this is the last one, and I'm too busy on other things to work on the next ones! #firstworldproblems

[mheon]

What are these new production-build jobs from? Don't recall seeing any CI work on this.

[rhatdan]

@lsm5 @cevich PTAL

[edsantiago]

That looks like the new packit thing (#15375). It merged before I got to review it. @lsm5 PTAL.

[lsm5]

error: Installed (but unpackaged) file(s) found:
   /usr/share/user-tmpfiles.d/podman-docker.conf

Did we miss this earlier ?

[edsantiago]

Merge collision, #15444

[lsm5]

bumped dist-git spec files to account for /usr/lib/tmpfiles.d/podman-docker.conf.

[lsm5]

@cevich looks like packit has much better status reporting in github UI compared to other tests.

[edsantiago]

So, that's what took me so long to review yesterday, and why I didn't finish. I was trying to figure out all the implications of cross-depending github and dist-git. I still don't think I understand it all, but ISTM that we can get into situations in which CI is deadlocked waiting for you to update dist-git; and then if you do update dist-git, other in-flight PRs will fail? I need to draw a full diagram.

[lsm5]

What are these new production-build jobs from? Don't recall seeing any CI work on this.

@mheon there's a new .packit.yaml which will run scratch koji builds using fedora's dist-git sources patched to build the PR commit. Good to check for build issues on all arches and fix them prior to merge. Packit will also allow running tests, but that seemed to be a bit more involved, so I'm gonna explore that in stages.

[lsm5]

So, that's what took me so long to review yesterday, and why I didn't finish. I was trying to figure out all the implications of cross-depending github and dist-git. I still don't think I understand it all, but ISTM that we can get into situations in which CI is deadlocked waiting for you to update dist-git; and then if you do update dist-git, other in-flight PRs will fail? I need to draw a full diagram.

AFAICT, the current packit jobs will fail if:

• there are new files installed. In this case it should be trivial to update the file list to accommodate new files. If the new files can't be added to dist-git right away, then I'd say we can/should ignore packit failures.

• there are actual build issues. In this case, this would be an early warning for us, which I see as a good thing.

[lsm5]

ugh, didn't notice the new file path

[edsantiago]

looks like packit has much better status reporting in github UI compared to other tests.

You mean the thing where it goes into spinning-yellow-circle when the test restarts, instead of red-X? Yeah, that REALLY irks me about Cirrus! And packit shows that it's possible to do it correctly!

[lsm5]

Given the new file is /usr/lib/*user-*tmpfiles.d/podman-docker.conf, it can't be included in dist-git AFAICT, unless I do some unholy wildcarding. So, let's ignore packit failures. I don't think it should block from auto-merging.

[lsm5]

I'll check with packit people if they have any alternatives for this issue.

[edsantiago]

Given the new file is /usr/lib/*user-*tmpfiles.d/podman-docker.conf, it can't be included in dist-git AFAICT

Meaning, #15444 violates FHS? If so, can you submit a podman PR to fix it, or tell me how to do so?

[lsm5]

Given the new file is /usr/lib/*user-*tmpfiles.d/podman-docker.conf, it can't be included in dist-git AFAICT

Meaning, #15444 violates FHS? If so, can you submit a podman PR to fix it, or tell me how to do so?

Nope, my bad. I do see systemd mention that path. I fixed spec file in the wrong place. Let me make a quick change and give it 1 last try.

[edsantiago]

This has merged, but I'm quite sure the problem is affecting all other in-flight PRs.

[lsm5]

This has merged, but I'm quite sure the problem is affecting all other in-flight PRs.

I pushed another spec file update to account for that path, correctly :D . Can you rerun the failures you see please?