Remember the installer here is just consuming "bootimages" - it's generally OK if it lags and/or is different from `machine-os-content`. In CI we have been living with it lagging; do we have a specific reason to try to synchronize it for GA other than it appearances?
> In CI we have been living with it lagging; do we have a specific reason to try to synchronize it for GA other than it appearances? Micah pointed out 0520 started using RHEL8 released content that is on the production CDN with signed RPMs from ART. To my outsider eyes, that seems like it's sitting on the fence between "cosmetic" and "actually useful". And there's nothing wrong with cosmetic synchronization anyway ;).
Landed.
Verified this bug with 4.1.0-0.nightly-2019-05-22-050858, and PASS. In 4.1.0-0.nightly-2019-05-21-060354, installer is using rhcos-410.8.20190508.1 (ami-02200f690a88f0819 in us-east-2) as boot image. In 4.1.0-0.nightly-2019-05-22-050858, installer is using rhcos-410.8.20190520.0 (ami-0649fd5d42859bdfc in us-east-2) as boot image. # oc get clusterversion NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version 4.1.0-0.nightly-2019-05-22-050858 True False 28m Cluster version is 4.1.0-0.nightly-2019-05-22-050858 # ./openshift-install version ./openshift-install v4.1.0-201905212232-dirty built from commit 71d8978039726046929729ad15302973e3da18ce release image registry.svc.ci.openshift.org/ocp/release@sha256:29e03d18fb7fe375bc5d103f22df3343fc40843a6acfbb52b785b7f3aee3921f
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2019:0758