The origin- gets dropped? I got the image name from https://quay.io/repository/openshift/origin-pod?tag=v4.0&tab=tags.

Oh, then yeah it needs to be the other way around.

Right, I see what I did there. Thanks for the fix!

/retest

/approve
/lgtm

/retest

So this has drift still, ugh:
I0228 21:55:30.673793 20978 daemon.go:1041] While getting MachineConfig master-c972857d9ccbede3699c273abb1ebd65, got: machineconfigs.machineconfiguration.openshift.io "master-c972857d9ccbede3699c273abb1ebd65" not found. Retrying..

At least though the installer PR got in, so we only need to land a change in this repo.

EDIT: Wait no I'm crazy, it's still outstanding openshift/installer#1292

OK I think we're actually back to my original theory - we have the image in the payload now 🎉 but need to have a no-op CLI option, land this PR, then land the installer one, then enable the CLI option.

Can I ask some questions about the pod/infra image? It's from here (equivalently here), right? And it's a sleeper to hold pod namespaces open? But CRI-O has its own and Kubernetes has its own. And the OpenShift Go seems to have forked off Kubernetes way back in openshift/origin#852. Then Kubernetes ported to C (kubernetes/kubernetes@f3690e2d5e, kubernetes/kubernetes#23009). Then CRI-O forked off. Then Kubernetes added SIGCHLD reaping (kubernetes/kubernetes@81d27aa2396, kubernetes/kubernetes#36853). Do we still want our very elderly Go to be the source of our pod-holding process?

On the SIGCHLD front, there's some reaping discussion in openshift/origin#1242 with a fix in openshift/origin#1264 (and then some revisiting in openshift/origin#17743 and openshift/origin#18992). That reaper now seems to only be launched by oc observe, which seems like an unlikely candidate for a generic, pod-holding process (but maybe we really do use oc for everything?).

Pulling the infra image from the release image (as in #471) makes sense to me, but we seem to have made an odd choice to provide that image (Kubernetes' pause.c seems to have the most active maintenance and maturity). Is there more background around that choice somewhere? I guess one benefit to getting this from the release image is that it will be easy to update later ;).

@wking I would open an issue in CRI-O and discuss there and talk to @mrunalp I guess. This feature comes from them and we're merely adding core to support that (though I agree on your points).

Can I ask some questions about the pod/infra image

That's an amazing comment even for you! I still wonder if you have scripts to do this kind of lookup or maybe a machine learning system 😉

Anyways I think we need all images to come from the release payload; can't be pulling random images we don't control particularly for critical infra.

Once we have that fixed, then we should definitely circle back and be sure we've picked up fixes like the SIGCHLD reaping.

(Honestly though it would be a lot saner if one could just tell the kernel to do it, but eh)

OK, this passed e2e-aws-op, so can someone lgtm it?

What's going on here is that we have pod in image-references but it's substituting an unused value. I believe that was the problem before, if there's something in image-references but it's not substituting anything then:

	if len(repositories) == 0 {
		glog.V(5).Infof("No images are mapped, will not replace any contents")
		return NopManifestMapper, nil
	}

So oc adm release new didn't end up using it.

Now with this again, the installer PR should be able to land, then we circle back here and do another PR to start using the image.

(Yes, this is all insane and we should parse the CVO directly)

/approve
/lgtm

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: cgwalters, runcom

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

The pull request process is described here