After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 743882 - size-based pruning
size-based pruning
Status: RESOLVED WONTFIX
Product: ostree
Classification: Infrastructure
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: OSTree maintainer(s)
OSTree maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2015-02-02 19:29 UTC by Colin Walters
Modified: 2018-08-17 18:59 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Colin Walters 2015-02-02 19:29:52 UTC
Not every system admin will want to keep binary history forever; right now the easy option is only:

 - Create a new repo, commit to it, archive (or delete) the old one, and swap  new one into place

We should support a "rolling" prune, like what backup systems support.  For example: ostree --repo=repo prune myos/x86_64/blah --refs-only --rolling-upto=20G" or so, where we delete older commits more aggressively.
Comment 1 Matthew Barnes 2015-02-04 14:13:13 UTC
This might just be my email caching experience talking, but to me "rolling" implies an invariant that's maintained automatically in the background, like a clean up action after an "ostree pull".

Would it make sense to support a max-history-size option for remotes, or would you prefer to keep the pruning explicit?
Comment 2 Matthew Barnes 2015-02-04 14:18:27 UTC
(I guess it would be an option for repos, not remotes - but you get what I mean.)
Comment 3 Colin Walters 2015-02-04 19:49:57 UTC
Pruning remotes is a related story, but for this bug I was thinking from the perspective of a repository owner.
Comment 4 Colin Walters 2015-07-30 18:44:20 UTC
At the moment we don't have a convenient command line way to prune the history of just one branch.

Further, we should have some sort of "tombstone" replacement for a commit when history is truncated.  This would allow mirrors to know the parent isn't available, and to stop rather than erroring out.
Comment 6 Colin Walters 2015-07-30 18:45:15 UTC
We could choose to have some of this functionality in https://github.com/cgwalters/ostree-scripts/ too.
Comment 7 Matthew Barnes 2015-08-04 13:08:57 UTC
(In reply to Colin Walters from comment #4)
> Further, we should have some sort of "tombstone" replacement for a commit
> when history is truncated.  This would allow mirrors to know the parent
> isn't available, and to stop rather than erroring out.

This reminded me of the End-of-Life notifications:
https://github.com/projectatomic/rpm-ostree/issues/142

Though this is kind of the reverse case, could it use a similar mechanism?  Embed some detached metadata in the commit whose parent got pruned ("parent-pruned")?
Comment 8 Colin Walters 2016-06-23 22:31:25 UTC
Tombstone commits landed.  We don't have any size-based pruning though which would still be nice.
Comment 9 André Klapper 2018-08-17 18:59:38 UTC
OSTree has moved to Github a while ago.
Furthermore, GNOME Bugzilla will be shut down and replaced by gitlab.gnome.org.

If the problem reported in this Bugzilla ticket is still valid, please report it to https://github.com/ostreedev/ostree/issues instead. Thank you!

Closing this report as WONTFIX as part of Bugzilla Housekeeping.