--ephemeral flag behavior defies --h description

[mrferris]

Running trin with the --h flag includes -e, --ephemeral Use temporary data storage that is deleted on exit but the data is not deleted.

Options:

1. Rename --ephemeral to --fresh, change description accordingly
2. Modify --ephemeral functionality to delete data on trin shutdown.

I'm in favor of 1 short term and 2 longer term.

I think that ephemeral provides more value than fresh does. fresh is doing work that we could easily do ourselves by specifying a unique data directory at trin boot, whereas ephemeral is doing work both for us (cleaning up after tests) and for users (I hate trying out new software and being afraid that it's gonna dump a ton of data to god-knows-where on your disk that will be there forever).

Context from #404 discussion:

@ogenev said:

One note on the --ephemeral flag:
The way it is implemented, it is not expected to clean the directories right after Trin closes. Why is that? I think as a user, we may still want to look into DB after termination. The main thing that --ephemeral does is to create a new path on every run in OS's temp folder. This way we guarantee that we always start with a clean database and we don't pollute the default Trin path, but we don't delete the directories automatically.

@carver said:

Oh this is a big surprise to me. The word ephemeral strongly suggests that everything from the run will be gone when it's done running. The only counter-example I could think of is if it is run on top of an existing DB, in which case the changes might persist. But to be consistent with the meaning of the word ephemeral, it would also be totally reasonable to refuse to start on top of an existing DB. It's not clear whether we should rename the flag to be something else (something like --fresh-start, because the current mechanics of the flag are valuable... or if we should modify the mechanics to match the name. That's a product question, and one I don't feel strongly about because I'm not using the flag myself either way. I usually want more control over things like port number, etc, than the flag would give me.

@ogenev said:

Yeah, maybe ephemeral is not the perfect word for this functionality but we are putting all the data into /tmp folder which purpose is to not persist the data. Lighthouse also uses tmp folder to store temporary data and I thought it is a better decision than trying to explicitly delete all folders after termination, I can't come up with a use case that would require exactly this.

@mrferris said:

I can see wanting that as a Trin contributor, for example for debugging DB operations, but what's a scenario in which a user would want to look at the raw data their now-destroyed node had collected? I think that there's a large if not complete overlap between a.) people who want to, for example, keep peertest data around so that they can inspect it after the peertest completes and b.) people who know how to modify one line in the peertest source to make it not ephemeral anymore. Whereas I can't think of any overlap of people who would want to inspect the data of an ephemeral node after it's gone and people who can't make that modification locally themselves.

[carver]

Piper also had this suggestion:

When I was doing this in the python implementation I came up with the --ephemeral flag which took care of establishing a temporary directory in which all data would be housed. In most cases the desired shutdown behavior would be to cleanup this directory (delete it and all of its contents), though it would almost definitely be valuable to be able to retain this information. I would recommend potentially combining these two approaches ad doing this:

• Implement --ephemeral mode that uses a temporary directory within XDG_CACHE_HOME, using the node-id prefix solution outlined here for determining the directory

• Leave some sort of marker in that directory to signal when the directory was last used

• Maybe make some form of automation that will cleanup this directory, or alternatively, make the --ephemeral flag automatically purge the oldest directories once there are too many.

[github-actions]

This issue is stale because it has been open for 42 days with no activity.

[github-actions]

This issue was closed because it has been inactive for 14 days since being marked as stale.