Forcing PLATFORM_ID to openstack on s390x systems

[jaypoulz]

No description provided.

[cgwalters]

This seems like it's trying to sidestep/replace a larger story around how Ignition fetches config on s390x.

In coreos/ignition#865 we added z/VM support

Some of the cosa commands basically directly use libguestfs to inject a config.

Why exactly are you trying to do this? What would it fix?

Is it for OpenShift installs with libvirt for testing? I think those are probably best done via the libguestfs path...

Or to say this more strongly, if the qemu platform definition isn't useful for s390x today, I think we should fix that rather than patching it here.

[jaypoulz]

I am inclined to agree.
Let me explain the context:

The goal of this patch is to address a symptom we're seeing way down the line in CI/CD for OpenShift on s390x.
For remote libvirt installations of OpenShift on s390x, we don't have fwd_cfg so we use the OpenStack config drive to inject the ignition config instead. The problem is that within a CI/CD job, the only thing that has access to information about the latest rhcos builds is the installer binary.

The installer binary simply creates the URL to the latest OpenStack image [1] based on the info in the rhcos.json [2].
[1] https://github.com/openshift/installer/blob/b13dcbfdc1eb30de6576cb7f73072856200aa028/pkg/rhcos/openstack.go
[2] https://github.com/openshift/installer/blob/236ddf58e118649c8fcb9a34d5bf5f080826d61b/data/data/rhcos.json

So the problem we're seeing in CI/CD is that this rhcos.json has been baked into the installer binary and symbols have been removed - so we can't crack it open to get at this information. Also, it would be a little gross to do it that way.

Our workaround would be to force ignition to always give us the image we want. Since openstack is the only working one for s390x for remote installs, we'd like to repoint it there.

I had a conversation with Prashanth - he recommends updating our cosa build to simply replace the qemu image with the openstack image instead. This would solve the the problem of the qemu image not being useful, while still enabling us to installs in CI/CD.

[jaypoulz]

The issue we have with libguestfs is that it cannot be used against a remote host.

[cgwalters]

So the problem we're seeing in CI/CD is that this rhcos.json has been baked into the installer binary and symbols have been removed - so we can't crack it open to get at this information.

See also openshift/installer#2092

[cgwalters]

I had a conversation with Prashanth - he recommends updating our cosa build to simply replace the qemu image with the openstack image instead. This would solve the the problem of the qemu image not being useful, while still enabling us to installs in CI/CD.

I think we want both to be available, same as x86_64 right?

[Prashanth684]

I had a conversation with Prashanth - he recommends updating our cosa build to simply replace the qemu image with the openstack image instead. This would solve the the problem of the qemu image not being useful, while still enabling us to installs in CI/CD.

I think we want both to be available, same as x86_64 right?

I was thinking for s390x , we could generate the qemu image with the platform id and oem id as openstack for s390x - just for 4.2 at least since we have a multi arch branch for cosa. That is not ideal though. With openshift/installer#2092, we could run the rhcos-metadata command to figure out the image details and pick the correct one ?

[crawford]

@cgwalters As you mentioned, coreos/ignition#865 adds support for zVM, but we are using KVM in our CI environment, so as I understand it those mechanisms aren't available. I would argue that it would be more appropriate (from a purely idealistic position) for Ignition's qemu provider to look at the config-drive when run on s390x, but this change was much less invasive.

[jaypoulz]

I've opened an alternative patch in cosa that can be used for 4.2. I think the long term fix is going to be for someone to go into: https://github.com/coreos/ignition/blob/3e633de1adb2afe8edcc184e3e8a28c40b96ea6b/internal/providers/qemu/qemu.go
and update it to work like:
https://github.com/coreos/ignition/blob/3e633de1adb2afe8edcc184e3e8a28c40b96ea6b/internal/providers/openstack/openstack.go

For now tho, it would be good to push on this or coreos/coreos-assembler#1004 for our CI jobs.

[lucab]

For reference, the underlying bug is coreos/ignition#825.

If there is some actual interest (and thus knowledgeable people) for a qemu platform on s390x architecture, it would be better to use such resources to properly investigate, design, and implement that.

[jaypoulz]

Closing this since we have short term workaround for 4.2:
coreos/coreos-assembler#1004

As well as a longer term workaround until the underlying issue is addressed:
coreos/ignition#905

For sake of completion, the underlying issue, as provided by lucab, is:
coreos/ignition#825