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

Design result reporting to to Result Store. #454

Closed
tejal29 opened this issue Jan 30, 2019 · 15 comments
Closed

Design result reporting to to Result Store. #454

tejal29 opened this issue Jan 30, 2019 · 15 comments
Assignees
Labels
kind/feature Categorizes issue or PR as related to a new feature. lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness.

Comments

@tejal29
Copy link
Contributor

tejal29 commented Jan 30, 2019

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.

@tejal29 tejal29 self-assigned this Jan 30, 2019
@bobcatfish
Copy link
Collaborator

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 bobcatfish changed the title Evaluate whether to use sidecar or Result CRD to upload results to Result Store. Design result reporting to to Result Store. Feb 21, 2019
@bobcatfish
Copy link
Collaborator

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

@bobcatfish
Copy link
Collaborator

oh hey

/assign @imjasonh

@vdemeester
Copy link
Member

/kind feature

@tekton-robot tekton-robot added the kind/feature Categorizes issue or PR as related to a new feature. label Nov 8, 2019
@imjasonh
Copy link
Member

imjasonh commented Nov 8, 2019

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

@bobcatfish
Copy link
Collaborator

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

@imjasonh
Copy link
Member

imjasonh commented Jan 9, 2020

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.

bobcatfish added a commit that referenced this issue May 28, 2020
Whenever I look for results docs on this page I get confused - "storing execution results" sounds to me like it has to with the results store work (#454).
tekton-robot pushed a commit that referenced this issue May 28, 2020
Whenever I look for results docs on this page I get confused - "storing execution results" sounds to me like it has to with the results store work (#454).
@shinji62
Copy link

shinji62 commented Jun 8, 2020

@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
Copy link
Contributor

MLBMatt commented Aug 14, 2020

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
Copy link
Member

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
Copy link
Collaborator

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.

@tekton-robot tekton-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Nov 12, 2020
@bobcatfish
Copy link
Collaborator

@wlynch is tackling this via TEP-0021

/remove-lifecycle stale
/assign wlynch

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

@tekton-robot tekton-robot removed the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Nov 12, 2020
@bobcatfish
Copy link
Collaborator

/lifecycle frozen

@tekton-robot tekton-robot added the lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. label Nov 12, 2020
@bobcatfish
Copy link
Collaborator

image

@bobcatfish
Copy link
Collaborator

I think we can consider this complete (or at least in progress enough that we don't need this issue open!) via TEP-0021 and https://github.com/tektoncd/results

Thanks @wlynch !! 🎉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Categorizes issue or PR as related to a new feature. lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness.
Projects
None yet
Development

No branches or pull requests

8 participants