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

Consider never deleting the runs #247

Closed
Ark-kun opened this issue Nov 14, 2018 · 8 comments
Closed

Consider never deleting the runs #247

Ark-kun opened this issue Nov 14, 2018 · 8 comments
Assignees

Comments

@Ark-kun
Copy link
Contributor

Ark-kun commented Nov 14, 2018

Some features (e.g. the ability to see where a piece of data came from) rely on the retention of runs. It's also extremely useful to be able to see the logs of those runs.

I propose using some mechanism to hide the runs (e.g. setting the hidden: true label) instead of deleting the runs altogether.

We should carefully gather the feedback about the users' need for run deletion.

@yebrahim
Copy link
Contributor

The current plan is not to completely delete runs, but to archive them.

@Ark-kun
Copy link
Contributor Author

Ark-kun commented Dec 7, 2018

I'm not sure archiving is good enough. For data provenance and caching it does not matter whether some run failed or not. Each data piece should have a source execution. It's convenient when all executions are in the same table.

@yebrahim
Copy link
Contributor

yebrahim commented Dec 8, 2018

Not sure I understand.
Archiving will keep runs around, it's just a convenience feature so that when you're listing resources, the API doesn't return everything, and you can keep the interface clean from old, ignored, or failed runs for example. You can still list archived resources and reference them.

@Ark-kun
Copy link
Contributor Author

Ark-kun commented Dec 12, 2018

when you're listing resources, the API doesn't return everything, and you can keep the interface clean from old, ignored, or failed runs for example.

This looks similar to what I meant by hiding. What do you think about implementing the feature using labels? We can have a default filter like hidden=false owner=<user>

@yebrahim
Copy link
Contributor

I'm not opposed to using labels for this in principle, but I wouldn't like blocking on its implementation. We can represent this in the UI however we like however.

@Ark-kun
Copy link
Contributor Author

Ark-kun commented Dec 12, 2018

I forgot we do not have labels yet. I wonder whether adding labels to the DB schema would be as easy as adding the archived/hidden flag...

@hongye-sun
Copy link
Contributor

I think we should let user to decide whether to keep the data or not. We might keep the data with a retention period, but I don't think we should keep the data beyond it. Even in managed service, we have to clean up user data if they decide to delete them for privacy reason.

@vicaire
Copy link
Contributor

vicaire commented Mar 27, 2019

Resolving. As @hongye-sun pointed out, users may need to delete runs permanently for one reason or another.

@vicaire vicaire closed this as completed Mar 27, 2019
magdalenakuhn17 pushed a commit to magdalenakuhn17/pipelines that referenced this issue Oct 22, 2023
* Add E2E tests for CLI

* Add JSON extension to golden files for highlighting

* Abstract out JSON expect statements for reuse

* Templatize tests
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants