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

better story for prod use #125

Open
amonks opened this issue Apr 5, 2024 · 2 comments
Open

better story for prod use #125

amonks opened this issue Apr 5, 2024 · 2 comments
Labels
idea Maybe we should build something like this? needs thought We have some decisions to make before moving on this.

Comments

@amonks
Copy link
Owner

amonks commented Apr 5, 2024

Keeping all the logs in memory is great for interactive use, but it's also inherently a memory leak, which could be uncomfortable for non-interactive use cases.

I use run "in prod" to orchestrate processes, and in that context, writing to a bunch of files (or even shipping the logs?) would be preferable.

Thinking about it, log files on disk might even be a good alternate way to implement the interactive viewer?

I wonder whether you'd want a single file or you'd want each stream to get its own file 🤔

One API for this might be a new value for the -ui flag.

@amonks amonks added needs thought We have some decisions to make before moving on this. idea Maybe we should build something like this? labels Apr 5, 2024
@amonks amonks changed the title do something about memory for prod use better story for prod use Apr 5, 2024
@jellevandenhooff
Copy link

some other fuel to add to the thinking fire: I think I'd like the ability to throw away all logs upon task restart for eg. running tests where I don't care about the last iteration. or at least I think I don't; maybe it'd be extra nice to have the ability to hide the previous logs most of the time but then show them in case I want to debug something.

@amonks
Copy link
Owner Author

amonks commented Apr 19, 2024

ooooh that's a nice idea.

I suppose a UI could parse logs to find restarts, but that seems kind of brittle. Maybe a more-explicit api for tailing runner events would be nice.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
idea Maybe we should build something like this? needs thought We have some decisions to make before moving on this.
Projects
None yet
Development

No branches or pull requests

2 participants