Proposal to remove Tekton resources #727
Conversation
openshift-ci-robot
added
the
release-note-none
SaschaSchwarze0
added
the
kind/design
SaschaSchwarze0
force-pushed
the
sascha-ep-remove-tekton-resources
branch
from
357d285 to
74ee01c
Compare
SaschaSchwarze0
force-pushed
the
sascha-ep-remove-tekton-resources
branch
3 times, most recently
from
5b00da2 to
f6291fc
Compare
| In our sample build strategies, we should support these two results as much as possible: | ||
|
|
||
| - `ko` supports to write an OCI image manifest file using the `--oci-layout-path` argument. The strategy needs to write that manifest to a temporary location, use a tool to extract the digest and size from the index.json file, and write this data to the result files. | ||
| - Kaniko supports to write an OCI image manifest file using the `--oci-layout-path` argument. Kaniko is based on scratch, as such, we cannot extend the existing build-and-push step to use some tool and run some extraction logic. We need to add an extra step. For this, we need to add volumeMounts to write the temporary file in the `build-and-push` step, and consume it in the following one to extract and store the results. |
There was a problem hiding this comment.
We could use the Kaniko debug image, which includes a shell: https://github.com/GoogleContainerTools/kaniko/blob/master/README.md#debug-image
There was a problem hiding this comment.
Hm, that might not work. Kaniko works by running all steps of the Dockerfile in its own container. When loading the FROM image, this overwrites the root file system of the Kaniko image which normally is not there as it is based on scratch. So, after Kaniko finished, you have no guarantee on what is still there (I might have missed it, but I think /busybox is not excluded when Kaniko for example cleans up the whole file system, beside /kaniko, between two stages). I think the main purpose of the debug image is to start the container with a shell to be able to debug things and manually start Kaniko inside the container. I think we would skate on thin ice to use debug to be able to run something after Kaniko finished.
| 7. Improve the implementation for HTTP sources to make it consistent with this design. | ||
| 8. Define and implement a well-defined set of exit codes per resource kind and use them in the BuildRun controller for an enhanced error reporting. | ||
|
|
||
| The goal to run as non-root is not covered in great detail in this proposal as some items are not 100 % clear to me yet, for example: |
There was a problem hiding this comment.
I'd rather remove this an an explicit goal of this EP, and just mention it as a nice-to-have that this enables later on. There are a number of open questions just for this item, and I don't want to block the rest of the improvement on answering these.
There was a problem hiding this comment.
Yeah, maybe, I was trying this out today. Current state: PSP enforces MustRunAsNonRoot, git image is built with ko and base image ubi-minimal, I have no security context on the container nor on the pod. It works. Based on k8s docs this imo must mean that ko is building images that have a USER directive. Need to check as which user the container actually runs.
|
Updating proposal, changes:
|
SaschaSchwarze0
force-pushed
the
sascha-ep-remove-tekton-resources
branch
from
f6291fc to
853028a
Compare
SaschaSchwarze0
force-pushed
the
sascha-ep-remove-tekton-resources
branch
from
853028a to
13c1e84
Compare
|
Updated proposal, changes:
|
There was a problem hiding this comment.
/lgtm
EDIT: Almost forgot to say, great work! nice one. I dont have any request for change, I think we discussed this one internally before, which make it easier for me to digest it faster. I think all the right ideas are in place, looking forward to contribute to the implementation part.
|
|
||
| ## Summary | ||
|
|
||
| Nothing really to add here. I would repeat the above motivation and the below goals if I would write something here. |
There was a problem hiding this comment.
You could always add something more generic, as in:
The deprecation of Tekton PipelineResources will block us from operating with input or output resources. These resources are valuable for Shipwright/Build because it allow us to input artifacts ( like source code from git ) and to surface metadata at the TaskRun Status level in an abstracted way. This EP proposes an approach on how to fullfill those future deprecated features in Tekton side.
|
/approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: qu1queee The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
openshift-ci-robot
added
the
approved
Changes
Related to Remove usage of Tekton resources #696.
This is still provisional, but looking for some feedback on some aspects.
It was honestly
complicatedimpossible at some places to keep this EP isolated. I know this makes it complex, but the design implications of getting rid of the resources at many places brought up topics that are in other EPs/issues/pull requests (listed in the risks section). I decided to touch those topics then. Otherwise, it would have imo been incomplete.For those interested to see code, here are two PoCs related to this work:
Submitter Checklist
Release Notes