Multi architecture support for catalog resources

[vdemeester]

A bit similar to tektoncd/pipeline#856, this issue is to track support for multi-architecture task in the catalog. Pipeline ships and is capable on running on multiple architecture today (not yet officially supported but still), thus the catalog should be able to mark task as multi-architecture compatible or not. This issue is to track ideas and thoughts on the subject.

This should cover:

• How to communicate a task can run on multiple architectures (through labels, …)
• How tools can use this (thinking of the hub, …)
• Guidelines and recommendations towards supporting multiple architectures

This will probably need a TEP or updates on the current catalog TEP, but we can discuss it here first.

/kind feature
/cc @tektoncd/catalog-collaborators @tektoncd/catalog-maintainers @tektoncd/hub-collaborators @tektoncd/hub-maintainers

[barthy1]

How to communicate a task can run on multiple architectures (through labels, …)

Would it make sense to use annotations, similar how it is done now for tags (tekton.dev/tags)?
Something like tekton.dev/architectures: linux/amd64, linux/s390x, windows/amd64. If there is no annotation, then default value is linux/amd64

How tools can use this (thinking of the hub, …)

tkn hub can filter tasks in search and installation based on architecture (extra --platform parameter?). And shown supported architectures as extra info column.
Hub can have UI extension to filter tasks in the UI based on architecture.

Guidelines and recommendations towards supporting multiple architectures

I guess it makes sense to ask for arch-specific CI/CD pipeline for supported tasks. For s390x and ppc64le cases current CI/CD setup can be extended to run also tests for tasks from catalog. The min requirement is to have images used in the task available for supported architecture.

@vdemeester What do you think? I can start working on TEP if the suggested ideas are reasonable..

[afrittoli]

See this thread too: https://tektoncd.slack.com/archives/CK3HBG7CM/p1621074374229700

[afrittoli]

A few thoughts:

• When no command is specified, the controller will fetch the step image to extract the original entrypoint. This causes the image that matches the architecture of the node where the controller runs to be used, which might not match the architecture of the node where the taskrun is going to be executed. TEP-0041 could help for that as @imjasonh noted.
• When a command is specified, the step definition could be valid one of the architectures / operating systems. We might need a way in Tekton and/or in the catalog to express alternate implementations of a step. This might be a really cool feature to have:

A random example (not advocating for this specific syntax):

  steps:
    - name: multi-arch-find
       image: alpine
       script: |
         #!/bin/sh
         find $(workspaces.source.path)
    - name: multi-arch-find. # multiple versions of a step with the same name could be used for specific arch/os
       image: PowerShell
       os: windows
       script: |
         Get-ChildItem -Path  $(workspaces.source.path) –Recurse

When using bundles we could use a manifest - like container images do - to specify different versions of a task depending on the arch / os. In any case this would suffer from a similar issue that container images have: the resolution to a specific step or task would happen in the controller, and the controller arch / os might not match that of the node where the task will be running.

[tekton-robot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale with a justification.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/lifecycle stale

Send feedback to tektoncd/plumbing.

[tekton-robot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten with a justification.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/lifecycle rotten

Send feedback to tektoncd/plumbing.

[tekton-robot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen with a justification.
Mark the issue as fresh with /remove-lifecycle rotten with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/close

Send feedback to tektoncd/plumbing.

[tekton-robot]

@tekton-robot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen with a justification.
Mark the issue as fresh with /remove-lifecycle rotten with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/close

Send feedback to tektoncd/plumbing.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.