providers/qemu: support Ignition block device on s390x and ppc64le #936
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
@Prashanth684 Can you sanity-check this on RHCOS s390x and ppc64le? Checking x86_64 here! |
absolutely. I already tested the initial commit, but I will test this also. |
jlebon
force-pushed
the
pr/backport-qemu-s390x
branch
from
0889a5b to
7327b42
Compare
Add experimental support for fetching Ignition configs via a virtio block device with serial `ignition`. The main advantage of this is that it is cross-platform. But for now, we only use it on platforms which don't support the QEMU firmware config approach, which are (of those we care about) s390x and ppc64le. We may end up using it across the remaining platforms. See related discussions in: coreos#928
jlebon
force-pushed
the
pr/backport-qemu-s390x
branch
from
7327b42 to
4621950
Compare
Following coreos/ignition-dracut#106 add a default `make install` rule that honors `DESTDIR`. Main motivation is hacking on ignition in a unified way with ostree, ignition-dracut and other projects using coreos-assembler. (Backport of coreos#858)
|
I updated this to also backport #858 to make testing easier. |
tested on s390x and ppc64le. lgtm! |
|
This is causing build failures on architectures other than amd64/arm64/ppc64le/s390x. |
Follow up here: #944 |
Prashanth684
added a commit
to Prashanth684/cluster-api-provider-libvirt
that referenced
this pull request
Mar 24, 2020
…90x/ppc64le Similar to dmacvicar/terraform-provider-libvirt#718 The method of mimicking what Openstack does for injecting ignition config works for images which have the provider as Openstack because ignition recognizes the platform and knows it has to get the ignition config from the config drive. For QEMU images, ignition supports getting the config from the firmware config device which is not supported by ppc64 and s390x. The workaround we have used thus far is to use the Openstack image on the QEMU platform but have this provider create the iso containing the ignition config. There was a discussion in ignition (coreos/ignition#928) to have a more QEMU based method of injecting ignition config and it was decided to use a virtio-blk device with a serial of ignition which ignition can recognize. This was mainly because with external devices, it is hard to tell if there is an issue with the device or if the kernel has not detected it yet if it has a long discovery phase. This PR reverts the ISO method used by Openstack and just creates a virtio-blk device through the QEMU command line options. Reference PR which supports ignition fetching through virtio-blk for QEMU: coreos/ignition#936
Prashanth684
added a commit
to Prashanth684/cluster-api-provider-libvirt
that referenced
this pull request
Mar 24, 2020
…90x/ppc64le Similar to dmacvicar/terraform-provider-libvirt#718 The method of mimicking what Openstack does for injecting ignition config works for images which have the provider as Openstack because ignition recognizes the platform and knows it has to get the ignition config from the config drive. For QEMU images, ignition supports getting the config from the firmware config device which is not supported by ppc64 and s390x. The workaround we have used thus far is to use the Openstack image on the QEMU platform but have this provider create the iso containing the ignition config. There was a discussion in ignition (coreos/ignition#928) to have a more QEMU based method of injecting ignition config and it was decided to use a virtio-blk device with a serial of ignition which ignition can recognize. This was mainly because with external devices, it is hard to tell if there is an issue with the device or if the kernel has not detected it yet if it has a long discovery phase. This PR reverts the ISO method used by Openstack and just creates a virtio-blk device through the QEMU command line options. Reference PR which supports ignition fetching through virtio-blk for QEMU: coreos/ignition#936
Prashanth684
added a commit
to Prashanth684/terraform-provider-libvirt
that referenced
this pull request
Mar 25, 2020
…x and ppc64 The method of mimicking what Openstack does for injecting ignition config works for images which have the provider as Openstack because ignition recognizes the platform and knows it has to get the ignition config from the config drive. For QEMU images, ignition supports getting the config from the firmware config device which is not supported by ppc64 and s390x. The workaround we have used thus far is to use the Openstack image on the QEMU platform but have this provider create the iso containing the ignition config. There was a discussion in ignition (coreos/ignition#928) to have a more QEMU based method of injecting ignition config and it was decided to use a virtio-blk device with a serial of ignition which ignition can recognize. This was mainly because with external devices, it is hard to tell if there is an issue with the device or if the kernel has not detected it yet if it has a long discovery phase. This PR reverts the ISO method used by Openstack and just creates a virtio-blk device through the QEMU command line options. Reference PR which supports ignition fetching through virtio-blk for QEMU: coreos/ignition#936
Prashanth684
added a commit
to openshift/terraform-provider-libvirt
that referenced
this pull request
Mar 27, 2020
…x and ppc64 The method of mimicking what Openstack does for injecting ignition config works for images which have the provider as Openstack because ignition recognizes the platform and knows it has to get the ignition config from the config drive. For QEMU images, ignition supports getting the config from the firmware config device which is not supported by ppc64 and s390x. The workaround we have used thus far is to use the Openstack image on the QEMU platform but have this provider create the iso containing the ignition config. There was a discussion in ignition (coreos/ignition#928) to have a more QEMU based method of injecting ignition config and it was decided to use a virtio-blk device with a serial of ignition which ignition can recognize. This was mainly because with external devices, it is hard to tell if there is an issue with the device or if the kernel has not detected it yet if it has a long discovery phase. This PR reverts the ISO method used by Openstack and just creates a virtio-blk device through the QEMU command line options. Reference PR which supports ignition fetching through virtio-blk for QEMU: coreos/ignition#936
Prashanth684
added a commit
to Prashanth684/cluster-api-provider-libvirt
that referenced
this pull request
Mar 27, 2020
…ignition for s390x/ppc64le Similar to dmacvicar/terraform-provider-libvirt#718 The method of mimicking what Openstack does for injecting ignition config works for images which have the provider as Openstack because ignition recognizes the platform and knows it has to get the ignition config from the config drive. For QEMU images, ignition supports getting the config from the firmware config device which is not supported by ppc64 and s390x. The workaround we have used thus far is to use the Openstack image on the QEMU platform but have this provider create the iso containing the ignition config. There was a discussion in ignition (coreos/ignition#928) to have a more QEMU based method of injecting ignition config and it was decided to use a virtio-blk device with a serial of ignition which ignition can recognize. This was mainly because with external devices, it is hard to tell if there is an issue with the device or if the kernel has not detected it yet if it has a long discovery phase. This PR reverts the ISO method used by Openstack and just creates a virtio-blk device through the QEMU command line options. Reference PR which supports ignition fetching through virtio-blk for QEMU: coreos/ignition#936
Prashanth684
added a commit
to Prashanth684/cluster-api-provider-libvirt
that referenced
this pull request
Mar 30, 2020
…ignition for s390x/ppc64le Similar to dmacvicar/terraform-provider-libvirt#718 The method of mimicking what Openstack does for injecting ignition config works for images which have the provider as Openstack because ignition recognizes the platform and knows it has to get the ignition config from the config drive. For QEMU images, ignition supports getting the config from the firmware config device which is not supported by ppc64 and s390x. The workaround we have used thus far is to use the Openstack image on the QEMU platform but have this provider create the iso containing the ignition config. There was a discussion in ignition (coreos/ignition#928) to have a more QEMU based method of injecting ignition config and it was decided to use a virtio-blk device with a serial of ignition which ignition can recognize. This was mainly because with external devices, it is hard to tell if there is an issue with the device or if the kernel has not detected it yet if it has a long discovery phase. This PR replaces the the method of ignition injection from a conig drive disk to a virtio-blk device which is specified through the QEMU command line options. Reference PR which supports ignition fetching through virtio-blk for QEMU: coreos/ignition#936
Prashanth684
added a commit
to Prashanth684/cluster-api-provider-libvirt
that referenced
this pull request
Mar 30, 2020
…ignition for s390x/ppc64le Similar to dmacvicar/terraform-provider-libvirt#718 The method of mimicking what Openstack does for injecting ignition config works for images which have the provider as Openstack because ignition recognizes the platform and knows it has to get the ignition config from the config drive. For QEMU images, ignition supports getting the config from the firmware config device which is not supported by ppc64 and s390x. The workaround we have used thus far is to use the Openstack image on the QEMU platform but have this provider create the iso containing the ignition config. There was a discussion in ignition (coreos/ignition#928) to have a more QEMU based method of injecting ignition config and it was decided to use a virtio-blk device with a serial of ignition which ignition can recognize. This was mainly because with external devices, it is hard to tell if there is an issue with the device or if the kernel has not detected it yet if it has a long discovery phase. This PR replaces the the method of ignition injection from a conig drive disk to a virtio-blk device. Reference PR which supports ignition fetching through virtio-blk for QEMU: coreos/ignition#936
openshift-cherrypick-robot
pushed a commit
to openshift-cherrypick-robot/cluster-api-provider-libvirt
that referenced
this pull request
Apr 28, 2020
…90x/ppc64le Similar to dmacvicar/terraform-provider-libvirt#718 The method of mimicking what Openstack does for injecting ignition config works for images which have the provider as Openstack because ignition recognizes the platform and knows it has to get the ignition config from the config drive. For QEMU images, ignition supports getting the config from the firmware config device which is not supported by ppc64 and s390x. The workaround we have used thus far is to use the Openstack image on the QEMU platform but have this provider create the iso containing the ignition config. There was a discussion in ignition (coreos/ignition#928) to have a more QEMU based method of injecting ignition config and it was decided to use a virtio-blk device with a serial of ignition which ignition can recognize. This was mainly because with external devices, it is hard to tell if there is an issue with the device or if the kernel has not detected it yet if it has a long discovery phase. This PR reverts the ISO method used by Openstack and just creates a virtio-blk device through the QEMU command line options. Reference PR which supports ignition fetching through virtio-blk for QEMU: coreos/ignition#936
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Add experimental support for fetching Ignition configs via a virtio
block device with serial
ignition.The main advantage of this is that it is cross-platform. But for now, we
only use it on platforms which don't support the QEMU firmware config
approach, which are (of those we care about) s390x and ppc64le. We may
end up using it across the remaining platforms.
See related discussions in:
#928
(Backport of #905).