Pipeline: kustomize package for tekton

Created on 16 Aug 2019  路  11Comments  路  Source: tektoncd/pipeline

Have you considered creating a kustomize package for TektonCD?

The Kubeflow project is starting to test TektonCD and we are heavy users of kustomize so we are creating a kustomize package.

kubeflow/manifests#264

Someone could potentially upstream that if it makes sense.

/cc @kkasravi

kinquestion lifecyclstale

Most helpful comment

The advantage of kustomize packages is that it makes it easy for us to compose applications into a stack of applications.

I would like to start including Tekton in Kubeflow stacks because we have a lot of places where we'd like to start using Tekton. In particular, I'd like to start being able to use Task's to define reusable ML tasks.

kubeflow/testing#613 - Tasks for running notebooks
kubeflow/fairing#454 - Use tasks for container building from within cluster/notebooks
kubeflow/katib#906 - Use Tekton tasks as "templates" for hyperpameter tuning.

These efforts aren't really blocked on a kustomize package for Tekton. We rolled our own
https://github.com/kubeflow/manifests/tree/master/tektoncd

The primary motivation for creating an upstream kustomize package in Tekton would be to upstream the maintenance cost of the Tekton manifests.

For example, each time we ship a Kubeflow version we'd probably like to ship the latest Tekton release. Right now we would have to go in and update the Kubeflow Tekton manifest to point to latest docker images.

There's a couple ways we could do this

  1. I think kustomize supports git/https links - so we could just point at YAMLs in the Tekton repos
  2. We could just periodically copy the upstream manifest to our repo

I think the problem with #1 is that from a user perspective remote dependencies could create a problem; e.g. if your running on prem and need to clone our repo to on prem. If our manfiests start having remote dependencies that becomes a lot more problematic.

So I think #2 is probably better. It creates toil but I think this is easy to automate. It would be great to have a Tekton Task/Tekton pipeline to copy some set of files from one repo to another repo and open up a PR.

We have started creating reusable tasks to these types of task.
https://github.com/kubeflow/testing/blob/master/apps-cd/pipelines/base/task.yaml

All 11 comments

@jlewi is this still something kubeflow wants/needs? I'm not very familiar with kustomize packages so if this is something you'd want I'd benefit from knowing what the package would provide. (And maybe it would be useful for our dogfooding efforts also? we use kustomize a lot for that! @afrittoli @vdemeester )

We have a kustomize plugin within the plumbing repo, but it's only for trigger resources. I guess we could have a general package, but I'm not aware of how this is then made available to others?

The advantage of kustomize packages is that it makes it easy for us to compose applications into a stack of applications.

I would like to start including Tekton in Kubeflow stacks because we have a lot of places where we'd like to start using Tekton. In particular, I'd like to start being able to use Task's to define reusable ML tasks.

kubeflow/testing#613 - Tasks for running notebooks
kubeflow/fairing#454 - Use tasks for container building from within cluster/notebooks
kubeflow/katib#906 - Use Tekton tasks as "templates" for hyperpameter tuning.

These efforts aren't really blocked on a kustomize package for Tekton. We rolled our own
https://github.com/kubeflow/manifests/tree/master/tektoncd

The primary motivation for creating an upstream kustomize package in Tekton would be to upstream the maintenance cost of the Tekton manifests.

For example, each time we ship a Kubeflow version we'd probably like to ship the latest Tekton release. Right now we would have to go in and update the Kubeflow Tekton manifest to point to latest docker images.

There's a couple ways we could do this

  1. I think kustomize supports git/https links - so we could just point at YAMLs in the Tekton repos
  2. We could just periodically copy the upstream manifest to our repo

I think the problem with #1 is that from a user perspective remote dependencies could create a problem; e.g. if your running on prem and need to clone our repo to on prem. If our manfiests start having remote dependencies that becomes a lot more problematic.

So I think #2 is probably better. It creates toil but I think this is easy to automate. It would be great to have a Tekton Task/Tekton pipeline to copy some set of files from one repo to another repo and open up a PR.

We have started creating reusable tasks to these types of task.
https://github.com/kubeflow/testing/blob/master/apps-cd/pipelines/base/task.yaml

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

/close

Send feedback to tektoncd/plumbing.

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
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.

/lifecycle stale

Send feedback to tektoncd/plumbing.

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

/lifecycle rotten

Send feedback to tektoncd/plumbing.

@tekton-robot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

/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.

/remove-lifecycle rotten
/remove-lifecycle stale
/reopen

@vdemeester: Reopened this issue.

In response to this:

/remove-lifecycle rotten
/remove-lifecycle stale
/reopen

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.

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
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.

/lifecycle stale

Send feedback to tektoncd/plumbing.

I would like to see a kustomize package be available.

Was this page helpful?
0 / 5 - 0 ratings