fedora-coreos-config: bump for in-place LUKS auto-growpart

[jlebon]

I.e. coreos/fedora-coreos-config#878 for
https://bugzilla.redhat.com/show_bug.cgi?id=1934174.

Colin Walters (1):
      manifest: Block plymouth

Jonathan Lebon (11):
      manifest: use DEFAULT_HOSTNAME=localhost
      transposefs: error out cleanly if less than 1G of RAM available
      overlay: add warning if rootfs < 8G
      README.md: Link to CoreOS CI docs
      overlay: temporarily ship `seq` in initrd
      overlay: nuke obsolete coreos-growpart.service preset
      overlay: rename coreos-growpart to ignition-ostree-growfs
      overlay/growfs: rename variable
      kola-denylist.yaml: add ext.config.podman.rootless-systemd
      overlay/growfs: fix in-place root reprovisioning detection
      overlay/growfs: support growing LUKS containers

Micah Abbott (2):
      manifests: improve ability to share downstream
      README: add blurb about interacting with CI jobs

[jlebon]

This is for 4.8. For 4.7, see #515.

[cgwalters]

build02 is having API server issues at the moment, it's being worked on.

[cgwalters]

/retest

[cgwalters]

/lgtm

[openshift-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

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

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 [cgwalters,jlebon]

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

[cgwalters]

For DPTP: this is a great example of the value of the nested virt approach IMO. Here we want to test LUKS encryption in Ignition at firstboot. We could e.g. talk to something like packet.net and do it on real physical hardware, but that's expensive and flaky. We could upload an image (AMI, OpenStack qcow2) to a cloud, but debugging early firstboot failures is painful and annoying. (Though we need to fix that, see coreos/ignition#585 ) And plus then we'd have to deal with garbage collecting those images.

Here our build+test framework is directly running qemu inside a pod w/nested KVM in GCP - this gives us a cheap way to sanity check things like this. Our CI appears just as a pod like the rest of the Prow pods, no need to worry about AMI leaks etc.