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.