OstreeRepo: add extensions directory

[jlebon]

It's very useful for third-party applications to have someplace to store
their data guaranteed to be on the same device as the repo (thus
ensuring hardlinks) while still being shielded away from any of OSTree's
timely garbage collections.

We create a new "extensions/" subdirectory where apps can include
whatever they wish in "extensions/myapp/". This subdirectory is
completely unmanaged by ostree.

NB: I didn't bother making it a member of the OstreeRepo proper since we
don't really use it for anything else yet.

[cgwalters]

It's worth noting the driver of this is coreos/rpm-ostree#107

So the patch is obviously pretty simple (though we could add a test that it exists). The question is - are there any better ways to do this? There's not any precedent I'm aware of to follow in the git project because it just doesn't use hardlinks for checkouts.

[jlebon]

The original reason why I moved data out of the main OSTree repo and into tmp/ was because of OSTree's auto-pruning function. Now, keeping it in tmp/ is also an issue as mentioned above because of the auto-cleanup.

At either of those possibilities above, it would work to have a config mechanism to tell ostree to back off. E.g. maybe:

[core]
unmanaged_refs=myapp;otherapp
# then all refs under myapp/* and otherapp/* are safe

Or if we go the tmp/ way:

[core]
unmanaged_tmp=myapp

[cgwalters]

There's two levels of GC going on here...random files in tmp/ which is present a day. This clearly needs enhancement. That's for preparing commits.

The other level is the "ostree admin" layer, which happens after you've made a commit. It sounds like the you're now talking about the latter. But these seem quite distinct, no? It may very well be we need both, but they do seem like different problems.

One wrinkle here is ostree_admin_prune() will use depth=0, so if for some reason someone wanted to retain history, they'd have to add refs for each commit..which could get awkward. We probably need some mechanism to keep track of refs written by ostree admin itself and only do depth=0 traverse for those.

[jlebon]

It sounds like the you're now talking about the latter. But these seem quite distinct, no? It may very well be we need both, but they do seem like different problems.

I was talking about both. Either one would be fine with me, though of course they have very different connotations.

One wrinkle here is ostree_admin_prune() will use depth=0

Yes, that's what I was referring to when I proposed unmanaged_refs.

We probably need some mechanism to keep track of refs written by ostree admin itself and only do depth=0 traverse for those.

Right, we could either default to pruning all refs and provide a whitelist, or pruning none of the refs except those we wrote ourselves. Not sure which makes the most sense.

I guess it depends on how we want to look at it. Do we want to encourage third-party apps to put stuff in there? Is the repo owned by OSTree, or does it just "happen to be" the repo that OSTree uses for storing deployments?

[cgwalters]

Definitely want to support non-"ostree admin" uses of the system repo. We have at least 3 now in progress that I know of myself:

• atomic system containers: "System Containers" mechanism design projectatomic/atomic#298
• xdg-app systemwide: https://mail.gnome.org/archives/ostree-list/2016-March/msg00004.html
• rpm-ostree package layering: Package layering coreos/rpm-ostree#107

[jlebon]

Right, that sounds good.
I'll close this PR and log an issue for now so we don't forget.

[cgwalters]

I wasn't arguing against extensions/ - after all I suggested it 😄 It does address the tmp/ issue, and that's important. But it was an offhand suggestion - I'm fine to discuss architecture in an issue and then go to a PR for code review if you prefer too.