Origin: Umbrella Issue: Make openshift projects architecture independent

Created on 16 Jul 2019  Â·  20Comments  Â·  Source: openshift/origin

Umbrella Issue: Make Openshift projects architecture-neutral

Goal: Make all the build scripts architecture-neutral to build successfully on non-amd64 platforms. There are few projects which are already architecture-neutral but not all the projects, so this issue is to track those missing projects and make them architecture-neutral.

List of projects need to be fixed:

picture mkumatag
👍4

Most helpful comment

Have sent the PRs for following ones:

Will update the list while sending PRs for the rest.

picture Pensu on 18 Jul 2019
👍2

All 20 comments

Have sent the PRs for following ones:

Will update the list while sending PRs for the rest.

Pensu picture Pensu on 18 Jul 2019
👍2

Here are some more PRs:

https://github.com/jimmidyson/configmap-reload/pull/34
https://github.com/openshift/etcd/pull/15
https://github.com/openshift/kubefed/pull/12
https://github.com/openshift/kubefed-operator/pull/42
https://github.com/openshift/openshift-tuned/pull/19
https://github.com/openshift/sriov-network-operator/pull/21

yselkowitz picture yselkowitz on 19 Jul 2019
👍1

Other issues for which we don't have patches yet:

  • ghostunnel: vendor/golang.org/x/sys/unix needs fixes/rebase for at least ppc64le
  • node-feature-discovery contains arch-specific code in source/cpu/cpu.go
yselkowitz picture yselkowitz on 19 Jul 2019

Other issues for which we don't have patches yet:

  • ghostunnel: vendor/golang.org/x/sys/unix needs fixes/rebase for at least ppc64le
  • node-feature-discovery contains arch-specific code in source/cpu/cpu.go

@yselkowitz thanks for the PRs, I have updated the first comment with all the PR you have submitted.
Will look into these issues as well.

mkumatag picture mkumatag on 22 Jul 2019

@mkumatag FYI I'm working on patches for node-feature-discovery. Will update once PRs are filed.

yselkowitz picture yselkowitz on 24 Jul 2019

@mkumatag FYI I'm working on patches for node-feature-discovery. Will update once PRs are filed.

sure, hope that will take care cpu feature for power platform as well(in fact we can just return empty string array for cpu features for power platform as we don't get any flags when we run lscpu command)

mkumatag picture mkumatag on 24 Jul 2019

In general, we are trying to fix both IBM Power LE & Z in tandem. PR filed:
https://github.com/kubernetes-sigs/node-feature-discovery/pull/262

yselkowitz picture yselkowitz on 24 Jul 2019

PR for ghostunnel:
https://github.com/operator-framework/ghostunnel/pull/9

yselkowitz picture yselkowitz on 24 Jul 2019

How are the multi-arch images going to be managed, regarding a registry? Is the near time plan to support manifest lists or distinct repositories for each architecture?

How one will make sure that the right arch-image lands on the right node?

zvonkok picture zvonkok on 24 Jul 2019

Red Hat uses manifest listing on its registry, and has since Power LE has been supported in various containers for ~1 year. But I'm not sure how that's relevant to this topic.

yselkowitz picture yselkowitz on 24 Jul 2019

By registry you mean the internal origin registry? Does quay.io has support
for manifest lists?

On Wed., Jul. 24, 2019, 4:11 p.m. Yaakov Selkowitz notifications@github.com
wrote:

Red Hat uses manifest listing on its registry, and has since Power LE has
been supported in various containers for ~1 year. But I'm not sure how
that's relevant to this topic.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/openshift/origin/issues/23385?email_source=notifications&email_token=AA4NPNWJMBEKLECQV7TK4XDQBCSPFA5CNFSM4ID5P2VKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2XKKZA#issuecomment-514762084,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA4NPNRKZFOWHTVSLRGUVMTQBCSPFANCNFSM4ID5P2VA
.

zvonkok picture zvonkok on 24 Jul 2019

Another PR:
https://github.com/openshift/cluster-api-provider-gcp/pull/38

Do you see any value to fixing the builds of AWS & Azure machine controllers?

yselkowitz picture yselkowitz on 24 Jul 2019

Do you see any value to fixing the builds of AWS & Azure machine controllers?

well, this can help when we have control plane installed on the non-amd64 platform and add AWS and Azure machines to the cluster, but not sure are there any such use-cases exist. At the moment those two can be a low priority

mkumatag picture mkumatag on 25 Jul 2019

By registry you mean the internal origin registry? Does quay.io has support for manifest lists?

As far as I know, openshift internal registry does not support fat manifest list, I remember reading quay.io started supporting fat manifest on an incremental basis. I'm not sure where the official openshift 4.x images have been pushed to quay or openshift cluster registry?

mkumatag picture mkumatag on 25 Jul 2019

More PRs:

https://github.com/openshift/cluster-image-registry-operator/pull/346
https://github.com/operator-framework/operator-marketplace/pull/236

yselkowitz picture yselkowitz on 31 Jul 2019

@mkumatag you are correct - we explicitly don't support fat manifest lists in the internal registry. The primary reason is that manifest lists are not compatible with the imagestream API.

fyi @dmage

adambkaplan picture adambkaplan on 1 Aug 2019

@mkumatag you are correct - we explicitly don't support fat manifest lists in the internal registry. The primary reason is that manifest lists are not compatible with the imagestream API.

fyi @dmage

that's right, will have to fix imagestream, imagestreamtag APIs to accommodate registry changes for manifest list media type.

mkumatag picture mkumatag on 1 Aug 2019

Would we have to? Would it be possible to add that support first and then work it into the imagestream way of working? I'm not familiar with the openshift image-registry codebase, so, for all I know this would break something. Just brainstorming ways that we could keep from having teams who take advantage of manifest lists now re-do their workflows when moving to OpenShift.

clnperez picture clnperez on 6 Aug 2019

Would we _have_ to? Would it be possible to add that support first and then work it into the imagestream way of working? I'm not familiar with the openshift image-registry codebase, so, for all I know this would break something. Just brainstorming ways that we could keep from having teams who take advantage of manifest lists now re-do their workflows when moving to OpenShift.

As internally registry is tightly coupled with openshift and creates an object of type imagestream for every image, so not really sure whether we can really ignore that part. I don't see any easy solution, a customer may end up maintaining their own registry which supports manifest or use an external one.

mkumatag picture mkumatag on 12 Aug 2019

All the mentioned PR are merged, hence closing this task now

mkumatag picture mkumatag on 30 Oct 2019
Was this page helpful?
0 / 5 - 0 ratings

Related issues

theone4ever picture theone4ever  Â·  3Comments
smugcloud picture smugcloud  Â·  5Comments
syui picture syui  Â·  3Comments
guangxuli picture guangxuli  Â·  4Comments
slmzig picture slmzig  Â·  3Comments