Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TEP-0018 Allow a Run to Specify a Default Bundle #210

Closed
wants to merge 1 commit into from

Conversation

coryrc
Copy link

@coryrc coryrc commented Sep 16, 2020

Allow a *Run to specify a bundle to lookup where to find references by
name instead of in the local cluster database.

Allow a *Run to specify a bundle to lookup where to find references by
name instead of in the local cluster database.
@tekton-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
To complete the pull request process, please assign chetan-rns
You can assign the PR to them by writing /assign @chetan-rns in a comment when ready.

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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@tekton-robot tekton-robot added the size/L Denotes a PR that changes 100-499 lines, ignoring generated files. label Sep 16, 2020
@coryrc
Copy link
Author

coryrc commented Sep 16, 2020

As specified in the proposal, I'm not sure how to make this observable. I believe Tasks/Pipelines from bundles will have annotations stating such? That could be enough?

- "@coryrc"
creation-date: 2020-09-15
last-updated: 2020-09-15
status: in pr review
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you could put proposed here 😝

Comment on lines +37 to +40
In a Pipeline, a Task can be referenced by name. This name is currently looked
up in the current namespace where the Pipeline and PipelineRun exist. It should
be possible for a PipelineRun or TaskRun to specify a bundle to be searched for
a match instead.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This builds upon TEP-0005, as commented on #205, should we have the syntax in an update TEP-0005 or a new one specifically for OCI bundle usage in tektoncd/pipeline API ?

## Motivation

When CI is defined in-repo, some method must be provided to test Tekton objects
during presubmit without altering Tasks being used by others. Additionally
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

presubmit should be defined here 👼

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Author

@coryrc coryrc Sep 17, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not a local pre-commit; it's like the "Review requested" section of this Github PR

I swear I was going to describe it later in the doc, sorry.


### Goals

Provide a different place to lookup Tekton objects when referenced solely by name.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think there is a missing TEP (or information in a TEP, most likely TEP-0005) : how do we refer bundle in tektoncd/pipeline API ? right now, it is not defined in any TEP, there is only examples.

Comment on lines +70 to +82
I have a repository where I have the entire CI/CD system using Tekton
resources defined in the repository. I wish to test commits to the repository
(presubmits) before allowing them to merge. I wish to support using the exact
resources when running locally.

My Pipelines refer to Tasks defined in-repo by name only and same for
PipelineRun->Pipeline and TaskRun->Task. I can still use `_Ref.bundle` if I
am referring to resources which are not created by this branch of the repository.

My presubmit test takes non-Run resources and creates a bundle. All PipelineRuns
and TaskRuns are modified to use the bundle as the default lookup environment. I
can now execute in the production namespace without interfering with the
environment in the existing namespace.
Copy link
Member

@vdemeester vdemeester Sep 17, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think, right now — without tekton oci bundle —, most "tekton as code" (aka CI/CD defined in the repository) approach are doing isolation by namespace (cc @afrittoli @dibyom @chmouel).

Assuming we have a way to reference bundle in the API and tooling to build bundle from a folder (or a set of files, or …), how would we solve this (without that TEP) ?

For pre-commit (local git hooks I assume), we would need to have a tool that (1) package the task/pipeline files into a bundle and (2) create a *Run object that refers those (resolves the pushed bundle, update on-the-fly the bundle reference). A similar workflow that comes to mind when describing this is ko — which does this for images and k8s yaml files. Something similar could be done for a tool like this, it could even be in tkn to be honest (or as a tkn plugin to start with) — tkn bundle resolve, tkn bundle run, …

Some open-questions then:

  • How the tools knows what bundle reference to replace on-the-fly ? ko uses the package path, and ko:// path, the tool could infer those from some conventions in the task/pipeline definition (some annotation, …)
  • Should it only work when bundle are specified ? (aka if I only have a task name, assuming it's on the cluster, the tool doesn't do anything)

In the light of this (if we agree, such a tool could exists), what is the benefit of having something server-side ? (default)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ko-type approach would mostly be equivalent, but not entirely. The machine you are launching Tekton from must have access and pathing to where the bundles are located; you could not control its permissions tightly. If server-side, cron jobs could be unable to access the Internet and only be able to create *Run custom resources in the cluster (though admittedly cron jobs are not usually security holes). Bundle locations must also be readable to users. Additionally, I think it's less "declarative" and more "imperative"? I am no k8s expert.

OTOH it means your bundle does not need to be readable by the cluster with Tekton.

Copy link
Author

@coryrc coryrc Sep 17, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am also about to do the hack where I generate a unique namespace per each, but that's fragile.

Comment on lines +86 to +88
I wish to support multiple repositories with CI/CD defined in-repo in the same
namespace without the possibility of name conflicts. The system creating
the PipelineRun must always specify a default bundle.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The tool (described above) could be used in such scenario, a bit like what is currently done in our tekton as code experiment — where we create a new namespace, here we would run that tool to pack and push the bundle and execute the *Run with it.

}
```

If `spec.lookup.bundle` is specified, the local database is never queried to
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wdym by local database ?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

etcd (sorry, I am not k8s expert)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The place where the Task ends up when you run kubectl apply -f my-task.yaml

Comment on lines +123 to +126
If any Tekton resources specify `bundle:` referring to bundles generated from
resources specified in the repository being modified, a presubmit test must be
aware of it and must modify the bundle reference to point to a version generated
from the current commit being tested.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The tool described above could do that. Now that I think of it, tektoncd/triggers could, in the long-term future, integrate that tools/behavior directly (cc @dibyom)

Comment on lines +145 to +147
1. All references could be required to have a bundle key. When you want to use
a custom version locally, you will need to modify the bundle to point to your
local copy. Tooling could make this trivial to do.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, I should have read the alternatives, my comments are describing this alternative I guess.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:-)

@vdemeester vdemeester added the kind/tep Categorizes issue or PR as related to a TEP (or needs a TEP). label Sep 17, 2020

## Proposal

Create a new key for PipelineRun and TaskRun called `spec.lookup.bundle`; use it
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is an implementation detail but since you mention the API, something about a lookup field feels like the wrong tense?

One thing that other fields in Tekton have is a "default" field. Eg, params have a value and a default. Perhaps a PipelineRun, and TaskRun object need a default block for things like this? Something like spec.defaults.bundle?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, I am not sufficiently knowledgeable about k8s to judge names! You all decide and I'll write it down!

@coryrc
Copy link
Author

coryrc commented Oct 26, 2020

People prefer a ko-like client-side tool.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/tep Categorizes issue or PR as related to a TEP (or needs a TEP). size/L Denotes a PR that changes 100-499 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants