Bug 1873034

Summary: [ppc64]Couldn't build index image on power machine
Product: OpenShift Container Platform Reporter: Anping Li <anli>
Component: OLMAssignee: Evan Cordell <ecordell>
OLM sub component: OLM QA Contact: Jian Zhang <jiazha>
Status: CLOSED NOTABUG Docs Contact:
Severity: high    
Priority: unspecified CC: aos-bugs, dslavens, jokerman, shurley
Version: 4.6Keywords: UpcomingSprint
Target Milestone: ---   
Target Release: 4.6.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: multi-arch
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-09-11 11:53:07 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1865777    

Description Anping Li 2020-08-27 08:21:25 UTC
Description of problem:
The index image build on AMD64 platforma couldn't be started on Power cluster.  I try to build an index image on the power machine. it failed as there isn't a ppc64 bundle image.


Version-Release number of selected component (if applicable):
openshift-ose-cluster-logging-operator-bundle

How reproducible:
Always

Steps to Reproduce:
1. build catalogimage on the power machine
2. opm index add --bundles $bundle_image_digest --tag quay.io/example/OCP4-index:latest
3. podman pull $bundle_image_digest 

*Actual results:*
No ppc64 bundle image

*Expected results:*
The index can be built on the power machine.  or the index image built on AMD64 can be used on the Power system.


*Additional info:*

Comment 8 Luke Meyer 2020-08-27 16:02:08 UTC
We stopped building metadata and bundle images multiarch because really they're archless -- just data -- and more builds are more opportunities for failure.

I had not thought about it until now, but since we are consuming operator manifests in images rather than via quay appregistry, architecture may matter. Certainly if OPM is expecting the bundle image to be the same arch as itself, and if OLM is expecting the index image to be the same arch as itself, both of those assumptions can be false. ART could certainly start building all arches on metadata/bundles, and it sounds like EXD's IIB does that for the index image.

Then again, arch may *not* matter. It's still inherently arch-less content. The problem may simply be that OPM and OLM are looking at a manifest list with one manifest, and that works fine where the arch matches the manifest, but not anywhere else. I don't see any reason why it should matter which arch built the image versus reads it. Could OPM and OLM prevent filtering by arch and just use whatever manifest is there? Or, failing that, always read (and for OPM, write) only the x86 manifest?

For that question I forward this to OLM. If the eventual solution is for ART to build bundle images multiarch, we can do that, just send it back. Bundle images will, I believe, be exposed to the customer, while metadata images are currently hidden.

I think you should be able to work around this particular problem by inspecting the bundle manifest list (I like to use "skopeo inspect --raw") to get the manifest and use that shasum directly as the bundle in OPM.

Comment 9 Luke Meyer 2020-08-27 16:04:38 UTC
Or likely I'm just ignorant and even data needs to be written in an arch-specific way.

Comment 11 Evan Cordell 2020-09-11 11:53:07 UTC
> If the eventual solution is for ART to build bundle images multiarch

We shouldn't need to do that - the only thing that should need to be multiarch is the index images right now.


@Anping I think the solutions outlined above should work for you (build a multiarch index so it can run in clusters, bundle images should just be amd64 / it doesn't really matter). I'm going to close this since I don't see any work for a particular team or product to do, but feel free to reopen (or open a new one) if there are more issues testing.