TEP-0079: Catalog Support Tiers - Ownership and Maintenance #793
Conversation
tekton-robot
added
the
kind/tep
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
tekton-robot
added
the
size/XL
jerop
changed the title
In tektoncd#599, we added the proposal for "Ownership and Maintenance" in [TEP-0079][tep-0079]. Since then, there have been significant changes to the Catalog: - [TEP-0110][tep-0110]: Decouple Tekton Catalog Organization from Resource Reference - [TEP-0115][tep-0115]: Tekton Catalog Git-Based Versioning In this change, we update [TEP-0079][tep-0079] to align with [TEP-0110][tep-0110] and [TEP-0115][tep-0115]. /kind tep [tep-0079]: https://github.com/tektoncd/community/blob/main/teps/0079-tekton-catalog-support-tiers.md [tep-0110]: https://github.com/tektoncd/community/blob/main/teps/0110-decouple-catalog-organization-and-reference.md [tep-0115]: https://github.com/tektoncd/community/blob/main/teps/0115-tekton-catalog-git-based-versioning.md
|
@tektoncd/catalog-maintainers please take a look |
| 5. The Catalog MUST support verification as proposed in [TEP-0091: Verified Remote Resources][tep-0091]. For now, | ||
| it MUST be published to a public OCI registry as a [Tekton Bundle][bundle] and signed by Tekton. In the future, it MUST | ||
| be updated to support accepted proposal of [TEP-0091: Verified Remote Resources][tep-0091]. Verification is discussed | ||
| further [below](#verified-remote-resources-1). |
There was a problem hiding this comment.
The referred section is not added, are we going to add it?
My question is how will the catalog expose the public keys information?
Suppose user A submit the signed resource, how does user B know where to get the public key to verify it when using the resource?
| url: https://github.com/tektoncd-catalog/kaniko | ||
| ``` | ||
|
|
||
| We could remove the existing `type` field because it should only be set to `"official"` when the Catalog is from the |
There was a problem hiding this comment.
is there a way to actually enforce the catalogs with type = official actually meet the requirements stated above?
| # official catalog for kaniko resources | ||
| - name: kaniko | ||
| org: tektoncd-catalog | ||
| type: official |
There was a problem hiding this comment.
nit: support-tier sounds more explicit than type
| adding two annotations: | ||
| * `tekton.dev/catalog` with the three part domain unique identifier | ||
| To make it easy for users to identify the source Catalog from the Hub, we propose adding two annotations: | ||
| * `tekton.dev/catalog` with the three-part domain unique identifier: `<catalog-tier>.<catalog-org>.<catalog-name>` |
There was a problem hiding this comment.
I get the rationale for having the tekon.dev/catalog label but why do we need the catalog tier as part of the identifier and why can't be its own label?
There was a problem hiding this comment.
So one "thing" the worries me a litlte bit, is the hub configuration that becomes complex. There is now a "versionning" type of catalog, … It kind-of make the hub more complex, because it now has to know different type of catalog layout — and will have to maintain any changes to them, etc…
I might be wrong but I think we want few things:
- We want the hub to be the index of as much Tekton "resource" as possible
- We want to be able mark Tekton "resource" with different "level" of trust (official, …)
- We want to allow users to easily add the Tekton "resource" they want to share to that index.
- In a centralized "community" repository, where there can be testing infrastructure available
- On their own repositories
If that's the case, then maybe we should de-couple the hub from the catalogs, and adopt a model/architecture a little bit closer "oci image registries" or "generic hub" like https://artifacthub.io/ for example. In these architectures, the role of the "catalog" and the "hub" are inverted. It's up to the catalog to publish (push) Tekton "resources" to the hub. The repositories documentation on ArtifactHub is pretty interesting there, and they do achieve different "status" (verified, official, …). One of the main benefit of this approach is that the hub doesn't need really need to care about any layout and it's actually very easy for anyone to contribute their task to tekton index.
A side note related to TEP-0110 and TEP-0115, is that artifacthub "install" button today depends on the catalog layout, see for tekton-cli for example
| Story: As a user of Tekton Pipelines, I want to be able to use `Tasks` and `Pipelines` from the Tekton Hub. I want to | ||
| know that I can rely on them to work as advertised. | ||
|
|
||
| Anti-story: As a user of Tekton Pipelines, I try to use a Task from the Tekton Hub but it turns out that it doesn't | ||
| actually work, e.g. the Result that the Task is supposed to produce is invalid and/or the Steps fail for unexpected | ||
| reasons. | ||
| Anti-story: As a user of Tekton Pipelines, I try to use a `Task` from the Tekton Hub, but it turns out that it doesn't | ||
| work, e.g. the `Result` that the `Task` is supposed to produce is invalid or the `Steps` fail for unexpected reasons. |
There was a problem hiding this comment.
We need to define "from where/who" in the Tekton Hub it comes from. Do we want the Hub to be more like docker.io or quay.io — where you do have that "trust" but you can (official images, …) — or do we want to drastically limit what is available from the Hub ?
| feedback and iterate quickly. | ||
|
|
||
| ### Goals | ||
|
|
||
| #### Ownership and Maintenance | ||
|
|
||
| Every resource in the *Tekton Catalog* needs to have Owners to maintain them. The Ownership needs to be distributed among | ||
| community members and Tekton maintainers to ensure that the workload is manageable and sustainable. | ||
| Every resource in Tekton Catalogs needs to have Owners to maintain them. The Ownership needs to be distributed among |
There was a problem hiding this comment.
By "Tekton Catalogs" we mean "catalogs that are in the tektoncd org or an org maintained by the tektoncd community", right ?
|
API WG - in discussion ... /assign @vdemeester |
tekton-robot
added
the
needs-rebase
|
@jerop: PR needs rebase. 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. |
|
Thanks to @vdemeester's comment above, we are migrating to Artifact Hub - tektoncd/hub#667 Handed off the migration, together with this TEP to @QuanZhang-William, so he'll open another PR updating TEP-0079 /close |
|
@jerop: Closed this PR. In response to this:
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. |
In #599, we added the proposal for "Ownership and Maintenance" in TEP-0079.
Since then, there have been significant changes to the Catalog:
In this change, we update TEP-0079 to align with TEP-0110 and TEP-0115.
/kind tep