Pipeline: Design result reporting to to Result Store.

[tejal29]

Expected Behavior

In #452 we will be designing a simple Result Store API which an endpoint will implement.

The status of Runs can be reported to this API as PipelineRuns and TaskRuns are in progress.

In this issue, we will be evaluating if we want to use a side car or a new Result CRD (or just a controller) to upload results to result store using the Result Store API, or if there is some other idea.

However, we want a way to report results of the Runs such as:

• "Status",
• "Time Started",
• "Time Finished"
• any other artifacts produced
• trigger type etc
  to result Store.

Actual Behavior

The status of any created Runs is not reported outside of the cluster they are run in.

This could be investigated by an outside tool by using kubectl or interacting with the kube API.

Additional Info

Log uploading will likely have a totally different design.

[bobcatfish]

if we want to use a side car or a new Result CRD to upload results to result store using the Result Store API

@tejal29 could you add more detail about what these are? i.e. what does "result CRD" (does this mean a CRD for results and a controller? what would the controller do?) mean in this context, and what is "result store API"?

[bobcatfish]

@tejal29 I updated the description a bit after talking about this with you offline

[bobcatfish]

oh hey

/assign @ImJasonH

[vdemeester]

/kind feature

[ImJasonH]

Project proposal doc: https://docs.google.com/document/d/1-XBYQ4kBlCHIHSVoYAAf_iC01_by_KoK2aRVO0t8ZQ0/edit

[bobcatfish]

What do you want to do for next steps here @ImJasonH ?

[ImJasonH]

Sorry for letting this linger.

Basically, the proposal from before seemed to be largely well received. Some people mentioned they had already built an ad hoc version of the same to be able to persist/query execution history, and would likely switch to using some more official Tekton solution if one existed.

I spoke to some people on the Grafeas team about this, and they seemed interested in prototyping with us a way of phrasing execution history details in the form Grafeas uses. Grafeas has a very flexible data model, each note can communicate one of a number of types of details, and we'd need to add an "execution"-type note to be able to persist these in Grafeas. Grafeas has a pluggable storage model, but effeciently storing and querying execution data once its written to Grafeas is still TBD based on our needs. It would at least give us a leg up on having to define an API and have a simple API frontend. If we expect users to also use Grafeas to store artifact metadata, it'd be nice to only have one system for this metadata. More exploration is needed.

If we decide that Grafeas isn't the right solution, we can just define our own API surface and (pluggable?) storage.

[shinji62]

@bobcatfish @ImJasonH
Hi, I would like to know what is the status of this feature ? We are starting to create our CI/CD in top of Tekton and having a store API that we can query or use to get the status a Run could be nice and avoid us to check Pipelinerun -> Taskrun -> pod logs.

Wondering how others people are dealing with logs a part of the global deamon and so on.

[MLBMatt]

This issue is unfortunately causing issues within our Tekton implementation. We (at MLB) run _a lot_ of jobs and we routinely hit our cluster pod limit for our build cluster. We have to resort to a daily cron job to delete the day's worth of jobs but this obviously isn't the best solution because we lose potentially valuable build data in the process.

We're still looking at ways to cache the logs (via Loki or some other logging solution) however losing all the residual Tekton metadata (plus the ease of using the UI for developers) is a loss for us when diagnosing potential build issues from the past.

Any update on where this is heading would be appreciated.

[ImJasonH]

Hi @MLBMatt and @shinji62

Sorry for the lack of updates/visibility on this. At this time we know pretty well that we need it (as you've noticed by now!) but haven't yet found anybody to prioritize working on it. There's some expeirmental work going on in experimental, but nothing I'd consider production-ready at this time.

If this is a useful base to build on, I'd say go ahead. If there's anything you think would be useful to contribute back, either in code or design/operational experience, that'd be great and very appreciated. I know a number of other users have built their own cron reapers, and some folks have mentioned they store old results off-cluster, but we just haven't coalesced that into progress on a Tekton-official solution yet. 😞

[tekton-robot]

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.

[bobcatfish]

@wlynch is tackling this via TEP-0021

/remove-lifecycle stale
/assign wlynch

And since this is in our tekton wide roadmap:
/lifecycle freeze

[bobcatfish]

/lifecycle frozen

[bobcatfish]