Include openshift-install binary with baremetal support in release image

[markmc]

Background

Release images currently contain two installer images:

1. installer - built from images/installer, the standard openshift-install binary for Linux systems
2. installer-artifacts - built from images/installer-artifacts, an openshift-install binary for MacOS layered over the installer image

There are other images which are built per commit but not included in the release image - libvirt-installer, upi-installer, and openstack-installer - however apparently all of these are used for CI only

(The installer image is listed as an "always include" image in 'oc adm release new' code - unclear how installer-artifacts gets included)

The baremetal platform is only available in openshift-install if it is built with TAGS="baremetal libvirt"

Builds with libvirt support are dynamically linked as there are no static builds of libvirt

The baremetal platform will be considered experimental in 4.2 and it will be listed in HiddenPlatformNames (currently openstack and vsphere are listed there)

Request

Since baremetal IPI support will not be available in the standard openshift-install binary, would it be acceptable to include a baremetal-installer image included in the 4.2 release image?

[markmc]

/label platform/baremetal

[russellb]

@eparis @crawford @smarterclayton would be interested in your feedback on this issue, thanks!

[smarterclayton]

I would prefer baremetal support in the binary but gated by tech preview than ship a second image. I recall a discussion with Alex about having a tech preview env var guard, did that happen yet (and/or would that be a better solution here)?

[smarterclayton]

I’m also not sure I care too much if we just listed baremetal in the choices but said “tech preview” next to it - but a tech preview flag that controls more than just platforms would be useful in general (and if we did that, I could still see us wanting to list it as tech preview).

To an end user, we already have the concept of a feature flag or feature set, I don’t see a huge reason not to extend / carry that concept into other tools that we have rather than make up a novel way to have users do it.

[russellb]

Hiding it in the choices really isn't a big deal. The bigger problem is that we can't build a single binary that also works for baremetal without imposing a new requirement to have libvirt installed. To avoid creating new compatibility challenges for the main installer binary, an alternative is to just bundle a second installer build in the release image only used for baremetal.

[stbenjam]

FWIW, baremetal doesn't have a survey wizard, so it'll never be shown in the list of platforms to configure interactively. IIRC hidden platforms only controls the ones with a survey, unless there's a different list other than the one in installconfig.go.

[russellb]

@abhinavdahiya FYI as well

[eparis]

I started looking at what it would take to write a wrapper library around all of the libvirt calls so we can use it via dlopen. It ain't simple. I suggest we take this and add support for a dlopen version in the future...

(I'm going to keep poking it today though)

[abhinavdahiya]

imo

I think it's going to be easier if rhhi moved away from current libvirt.. I'm not sure why you guys choose it in first place when you guys already knew it couldn't be shipped to the customers...

Anyways another option is rhhi use https://github.com/digitalocean/go-libvirt to build a libvirt terraform that doesn't need c bindings

[russellb]

imo

I think it's going to be easier if rhhi moved away from current libvirt.. I'm not sure why you guys choose it in first place when you guys already knew it couldn't be shipped to the customers...

Anyways another option is rhhi use https://github.com/digitalocean/go-libvirt to build a libvirt terraform that doesn't need c bindings

happy to discuss alternatives for 4.3, but a major change like that isn't practical for 4.2

[eparis]

go-libvirt uses non-stable ABI which the core libvirt team has EXPLICITLY said they can, and will, break in the future. Even the go-libvirt project calls out up front that you need to generate and build their code with the exact version of libvirt you use. This makes is completely non-portable and not an option.

[russellb]

OK - so should we put up PRs to include a baremetal build of openshift-install for 4.2? I don't really see any other practical way to resolve this in 4.2.

Support for dlopen sounds like a nice improvement to pursue for a future release.

[dhellmann]

Do we have a decision on what approach to take here?

[stbenjam]

@eparis @abhinavdahiya Anything I can do to help move this forward? I opened openshift/release#4640 to build a baremetal-installer container like we do for other platforms, is that an acceptable approach for 4.2? How do we get it included with the release?