Re: Scalability of OSTree

["Jasper St. Pierre" <jstpierre mecheye net>]

Hey, so I took this off-list for a bit because Colin asked me to
explain our situation in more detail, and I wasn't sure what I could
say publicly.

Basically, we have a system where we want to deploy streams of
content, and back-of-the-napkin numbers meant we would be getting
roughly 80-100 of those a week, as a lower bound...

I wasn't happy with an ever-growing summary file, but currently the
summary file is seen as a chain-of-trust across everything in the
repo, so it's not like we have many other choices (this mirrors how
yum's repomd.xml file and apt's Releases file are signed as a chain of
trust as well...) There was talk about signing the detached heads for
static deltas, but that becomes more and more complex.

Currently, the best option we have, which Colin suggested, is to do
some rough grouping of these content streams, and split it into
multiple repos.

Given that we might also want additional features like smart servers,
encrypted objects, more complex content-type negotiation and other
features like that, it might be a better idea to implement our own
system for this.

Also, Alex, have you given any thought into how you would do paid-for
applications or other things like IAPs in xdg-app, or do you consider
that out-of-scope?

It would also be interesting to perhaps see if we could sync up with
the Steam people, since they also have a fairly large production
distribution and update service that supports paid subscriptions, and
they are also interested in xdg-app.

On Fri, Dec 4, 2015 at 10:16 AM, Colin Walters <walters verbum org> wrote:
> On Fri, Dec 4, 2015, at 01:07 PM, Jasper St. Pierre wrote:
> > I think that makes sense, but since a "repo" in our / xdg-app's case
> > might contain thousands if not hundreds of thousands of branches (some
> > of our internal talk has been assuming stuff like ~100 new branches a
> > week), it seems like OSTree isn't designed to work well for the scale
> > we need.
>
> I don't understand branches on that scale; are you doing a branch-per
> release and using them like tags?  (If OSTree had tags, but note you
> can kind of simulate this using the ostree.version metadata and
> the fetcher better understands them now)
>
> There's always multiple repositories too remember.
>
> > I think we'll work on an independent system for shipping content to
> > users. Thanks.
>
> That may make sense, but it's hard for me to talk about this
> without having *some* idea of what the content is and how
> it's modeled.
>
> At least if you're doing a new format, you'll likely want binary-level
> deltas, and I think our work on https://github.com/mendsley/bsdiff
> is reusable.



-- 
  Jasper