Added support for s390x and ppc64le via catalog source

[R3hankhan123]

Updated build image workflow to prepare Multi-arch for authorino-operator-catalog. Tested locally and deployed via the steps given in the readme The pr was co authored by @Deepali1999 and @R3hankhan123

[R3hankhan123]

@guicassolato @jasonmadigan @willthames Please review the changes for supporting authorino-operator-catalog image for s390x & pp64cle

[R3hankhan123]

Hi @R3hankhan123.

First and foremost, thank you for this PR! Indeed we haven't been building the catalog images for s390x and ppc64le arches – only the operator and bundle images.

I do have a few concerns with the proposed approach nonetheless, starting with the substitution of buildah-build for a custom script. This would make Authorino the only component of Kuadrant not using buildah-build for any of its container images in CI.

Provided Buildah supports s390x and ppc64le, any particular reason why not to keep it, maybe by adding the two arches here? Did you have any issues with the current approach and supporting these arches?

I've left other comments as well. Hopefully we'll be able iterate over those together and continue with the work on this PR because it is indeed very much needed.

By adding s390x and ppc64le in buildah argument catalog image is generated with x86 opm binary. Thats the reason we are using opm binary for each architecture to generate catalog image in the scripts.

[R3hankhan123]

Hi @guicassolato, can you provide further comments based on the reply

[R3hankhan123]

@guicassolato is there any slack channel where we can discuss your concerns regarding the PR as its being dragged on

[guicassolato]

@guicassolato is there any slack channel where we can discuss your concerns regarding the PR as its being dragged on

@R3hankhan123, you can find us all at the #kuadrant channel in the Kubernetes Slack workspace.

I think the 2 main concerns at this point are:

1. Ensure we're not rolling back to SQLite-based catalogs. I see you've replied to that, though I cannot confirm if that OpenShift deprecation notice means what you say it does indeed. I need somebody else with more experience on that than myself to open the generated catalog images and approve the PR regarding this point of the catalog format.
2. Currently, if only for amd64 and arm64 architectures, we cannot push latest and SHA-tagged catalog images to registry in two separate image manifests. These two image tags must be linked into a single image manifest in the registry, until the head of main changes and latest is rebuilt and linked again to another SHA. There are automation in QE that depends on this link.

[R3hankhan123]

Hi @guicassolato, I have made the catalog source filed based and now also the tags are linked

[R3hankhan123]

@guicassolato is there any slack channel where we can discuss your concerns regarding the PR as its being dragged on

@R3hankhan123, you can find us all at the #kuadrant channel in the Kubernetes Slack workspace.

I think the 2 main concerns at this point are:

1. Ensure we're not rolling back to SQLite-based catalogs. I see you've replied to that, though I cannot confirm if that OpenShift deprecation notice means what you say it does indeed. I need somebody else with more experience on that than myself to open the generated catalog images and approve the PR regarding this point of the catalog format.
2. Currently, if only for amd64 and arm64 architectures, we cannot push latest and SHA-tagged catalog images to registry in two separate image manifests. These two image tags must be linked into a single image manifest in the registry, until the head of main changes and latest is rebuilt and linked again to another SHA. There are automation in QE that depends on this link.

Both the points have been addressed in the latest changes

[R3hankhan123]

Hi @guicassolato any more changes to be made?

[didierofrivia]

@R3hankhan123 Hey thanks for your time and the interest in our project! I'm a bit confused in your approach, you say you can't use buildah because the catalog image is generated with x86 opm binary...

Hi @R3hankhan123. First and foremost, thank you for this PR! Indeed we haven't been building the catalog images for s390x and ppc64le arches – only the operator and bundle images. I do have a few concerns with the proposed approach nonetheless, starting with the substitution of buildah-build for a custom script. This would make Authorino the only component of Kuadrant not using buildah-build for any of its container images in CI. Provided Buildah supports s390x and ppc64le, any particular reason why not to keep it, maybe by adding the two arches here? Did you have any issues with the current approach and supporting these arches? I've left other comments as well. Hopefully we'll be able iterate over those together and continue with the work on this PR because it is indeed very much needed.

By adding s390x and ppc64le in buildah argument catalog image is generated with x86 opm binary. That's the reason we are using opm binary for each architecture to generate catalog image in the scripts.

The resulting docker image created with opm is referencing the latest tag as default which is build for those multi archs needed, that's not enough? how is that failing when you get to use the catalog image resulting from buildah with s390x and ppc64le? Do you have them hosted somewhere? Have you checked buildah multi arch examples ?

In the case one need to directly specify the base opm image in the catalog dockerfile, I would choose to craft the catalog passing the arch as matrix strategy in GH workflow, but still rely on buildah and the scripts we have in place, opening the make catalog target to accept the arch env so it can add the -i flag accordingly, then using buildah in the next step to build the image as part of the matrix iteration. What I mean is that your proposing to execute a script which might not work as expected on GH workflows than locally and changes radically the way we are running our pipelines jobs.

Probably something like this : https://github.com/Kuadrant/authorino-operator/pull/222 , would that be Ok for your usecase?

[R3hankhan123]

@R3hankhan123 Hey thanks for your time and the interest in our project! I'm a bit confused in your approach, you say you can't use buildah because the catalog image is generated with x86 opm binary...

Hi @R3hankhan123. First and foremost, thank you for this PR! Indeed we haven't been building the catalog images for s390x and ppc64le arches – only the operator and bundle images. I do have a few concerns with the proposed approach nonetheless, starting with the substitution of buildah-build for a custom script. This would make Authorino the only component of Kuadrant not using buildah-build for any of its container images in CI. Provided Buildah supports s390x and ppc64le, any particular reason why not to keep it, maybe by adding the two arches here? Did you have any issues with the current approach and supporting these arches? I've left other comments as well. Hopefully we'll be able iterate over those together and continue with the work on this PR because it is indeed very much needed.

By adding s390x and ppc64le in buildah argument catalog image is generated with x86 opm binary. That's the reason we are using opm binary for each architecture to generate catalog image in the scripts.

The resulting docker image created with opm is referencing the latest tag as default which is build for those multi archs needed, that's not enough? how is that failing when you get to use the catalog image resulting from buildah with s390x and ppc64le? Do you have them hosted somewhere? Have you checked buildah multi arch examples ?

In the case one need to directly specify the base opm image in the catalog dockerfile, I would choose to craft the catalog passing the arch as matrix strategy in GH workflow, but still rely on buildah and the scripts we have in place, opening the make catalog target to accept the arch env so it can add the -i flag accordingly, then using buildah in the next step to build the image as part of the matrix iteration. What I mean is that your proposing to execute a script which might not work as expected on GH workflows than locally and changes radically the way we are running our pipelines jobs.

Probably something like this : #222 , would that be Ok for your usecase?

Hi @didierofrivia the PR you have raised, when I ran the workflow and noticed that the images were being overwritten ie amd64's image was being overwritten by arm64 and so on

rehankhan@Rehans-MacBook-Pro Documents % podman pull quay.io/r3hankhan/authorino-operator-catalog:latest
Trying to pull quay.io/r3hankhan/authorino-operator-catalog:latest...
Getting image source signatures
Copying blob sha256:aa97670cb9dee5ec6b3056e0789422f2adc072a268fd881fbd6fb1151162ce57
Copying blob sha256:ae475359a3fb8fe5e3dff0626f0c788b94340416eb5c453339abc884ac86b671
Copying blob sha256:1cd0595314a53d179ddaf68761c9f40c4d9d1bcd3f692d1c005938dac2993db6
Copying blob sha256:7062267a99d0149e4129843a9e3257b882920fb8554ec2068a264b37539768bc
Copying blob sha256:f89d6e2463fc5fff8bba9e568ec28a6030076dbc412bd52dff6dbf2b5897a59d
Copying blob sha256:25d123725cf91c20b497ca9dae8e0a6e8dedd8fe64f83757f3b41f6ac447eac0
Copying config sha256:93f8d113d3d8962d3f235f9c1792aca0bec1730d2429a037e81f7cf0f3581212
Writing manifest to image destination
WARNING: image platform (linux/amd64) does not match the expected platform (linux/arm64)
93f8d113d3d8962d3f235f9c1792aca0bec1730d2429a037e81f7cf0f3581212

[didierofrivia]

Hi @R3hankhan123, have you tried specifying the arch when you pull the image? as in

podman pull quay.io/r3hankhan/authorino-operator-catalog:latest --arch=linux/arm64

OR

docker pull quay.io/r3hankhan/authorino-operator-catalog:latest --platform linux/arm64

Let me know how it goes.

[R3hankhan123]

Hi @R3hankhan123, have you tried specifying the arch when you pull the image? as in

podman pull quay.io/r3hankhan/authorino-operator-catalog:latest --arch=linux/arm64

OR

docker pull quay.io/r3hankhan/authorino-operator-catalog:latest --platform linux/arm64

Let me know how it goes.

@didierofrivia I am getting this

rehankhan@Rehans-MacBook-Pro Documents % podman pull quay.io/r3hankhan/authorino-operator-catalog:test --arch=linux/arm64
Trying to pull quay.io/r3hankhan/authorino-operator-catalog:test...
Getting image source signatures
Copying blob sha256:c8022d07192eddbb2a548ba83be5e412f7ba863bbba158d133c9653bb8a47768
Copying blob sha256:2e4cf50eeb92ac3a7afe75e15d96a26dee99449f86b46c75b5d95f4418a5bca0
Copying blob sha256:4d4401f0320bd6f39c22d9a4a0eba68686c97d1928363283fc47ba8a8dee6382
Copying blob sha256:6f4cfee9177b9f884e8d86b48261a25094b2fcea1a7920919f47ea00712dbee8
Copying blob sha256:0f8b424aa0b96c1c388a5fd4d90735604459256336853082afb61733438872b5
Copying blob sha256:d858cbc252ade14879807ff8dbc3043a26bbdb92087da98cda831ee040b172b3
Copying blob sha256:d557676654e572af3e3173c90e7874644207fda32cd87e9d3d66b5d7b98a7b21
Copying blob sha256:1069fc2daed1aceff7232f4b8ab21200dd3d8b04f61be9da86977a34a105dfdc
Copying blob sha256:b40161cd83fc5d470d6abe50e87aa288481b6b89137012881d74187cfbf9f502
Copying blob sha256:3f4e2c5863480125882d92060440a5250766bce764fee10acdbac18c872e4dc7
Copying blob sha256:80a8c047508ae5cd6a591060fc43422cb8e3aea1bd908d913e8f0146e2297fea
Copying blob sha256:c57d5d2ad6083e98b301e2cb9283489173321ca77397fb6c150bfda946173fdb
Copying blob sha256:ba63ca86b039286f74b2529ac458da1de06035b23bd9b74f2fae2484c30700c0
Copying blob sha256:c072e97f89853830431248238603055ecfb103c6ad3386e3ff8fd46fc9beace6
Copying blob sha256:31b3e74066eb1f3153fceede0b1299ee0492c1573dcf5d6a8181b12b5b3bc788
Copying blob sha256:90f7e50e911c59ef9f96acedce3ac546a20147adf3c8fe2855e8010ac3ba227e
Copying config sha256:b5a7ac7e7cfaf4f837600c1f244ec9c3715ba9c445c37cf1fedf06711e1e3f0b
Writing manifest to image destination
WARNING: image platform (linux/ppc64le) does not match the expected platform (linux/linux/arm64)
b5a7ac7e7cfaf4f837600c1f244ec9c3715ba9c445c37cf1fedf06711e1e3f0b

[didierofrivia]

@R3hankhan123 Could you try first podman pull quay.io/kuadrant/authorino-operator-catalog:test-builda-multiarchs --arch=linux/ppc64le or the arch you want to try out (corresponding to https://github.com/Kuadrant/authorino-operator/pull/224)... and if that doesn't work, there are also the following images: quay.io/kuadrant/authorino-operator-catalog:building-multiarch-catalogs-{ARCH} from this PR: https://github.com/Kuadrant/authorino-operator/pull/222.

Cheers!

[R3hankhan123]

@didierofrivia whn I am trying to pull image corresponding to #224 I am getting the following

podman pull quay.io/kuadrant/authorino-operator-catalog:test-builda-multiarchs --arch=linux/s390x  
Trying to pull quay.io/kuadrant/authorino-operator-catalog:test-builda-multiarchs...
Error: choosing an image from manifest list docker://quay.io/kuadrant/authorino-operator-catalog:test-builda-multiarchs: no image found in manifest list for architecture linux, variant "s390x", OS linux

But I am able to pull the image corresponding to #222

[R3hankhan123]

@R3hankhan123 Hey thanks for your time and the interest in our project! I'm a bit confused in your approach, you say you can't use buildah because the catalog image is generated with x86 opm binary...

Hi @R3hankhan123. First and foremost, thank you for this PR! Indeed we haven't been building the catalog images for s390x and ppc64le arches – only the operator and bundle images. I do have a few concerns with the proposed approach nonetheless, starting with the substitution of buildah-build for a custom script. This would make Authorino the only component of Kuadrant not using buildah-build for any of its container images in CI. Provided Buildah supports s390x and ppc64le, any particular reason why not to keep it, maybe by adding the two arches here? Did you have any issues with the current approach and supporting these arches? I've left other comments as well. Hopefully we'll be able iterate over those together and continue with the work on this PR because it is indeed very much needed.

By adding s390x and ppc64le in buildah argument catalog image is generated with x86 opm binary. That's the reason we are using opm binary for each architecture to generate catalog image in the scripts.

The resulting docker image created with opm is referencing the latest tag as default which is build for those multi archs needed, that's not enough? how is that failing when you get to use the catalog image resulting from buildah with s390x and ppc64le? Do you have them hosted somewhere? Have you checked buildah multi arch examples ?

In the case one need to directly specify the base opm image in the catalog dockerfile, I would choose to craft the catalog passing the arch as matrix strategy in GH workflow, but still rely on buildah and the scripts we have in place, opening the make catalog target to accept the arch env so it can add the -i flag accordingly, then using buildah in the next step to build the image as part of the matrix iteration. What I mean is that your proposing to execute a script which might not work as expected on GH workflows than locally and changes radically the way we are running our pipelines jobs.

Probably something like this : #222 , would that be Ok for your usecase?

@didierofrivia @guicassolato, now the workflows will build catalog images using buildah

The workflow will be something like this

[codecov-commenter]

:warning: Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 61.78%. Comparing base (d40dba0) to head (7a7a37c). Report is 14 commits behind head on main.

Additional details and impacted files

```diff @@ Coverage Diff @@ ## main #214 +/- ## ======================================= Coverage 61.78% 61.78% ======================================= Files 2 2 Lines 785 785 ======================================= Hits 485 485 Misses 249 249 Partials 51 51 ``` | [Flag](https://app.codecov.io/gh/Kuadrant/authorino-operator/pull/214/flags?src=pr&el=flags&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=Kuadrant) | Coverage Δ | | |---|---|---| | [unit](https://app.codecov.io/gh/Kuadrant/authorino-operator/pull/214/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=Kuadrant) | `61.78% <ø> (ø)` | | Flags with carried forward coverage won't be shown. [Click here](https://docs.codecov.io/docs/carryforward-flags?utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=Kuadrant#carryforward-flags-in-the-pull-request-comment) to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[didierofrivia]

@R3hankhan123 Can you confirm that https://github.com/Kuadrant/authorino-operator/pull/222 solves your needs then?

[R3hankhan123]

@R3hankhan123 Can you confirm that #222 solves your needs then?

@didierofrivia PR #222 meets our needs just that the common manifests are not being created, but i have resolved that in my latest code change

[R3hankhan123]

After discussing with @didierofrivia , PR #222 will work for our use case. Cheers!!