Re: Storing collection ref (collection ID + ref) in the commit metadata

[Krzesimir Nowak <krzesimir kinvolk io>]

On Tue, Jun 27, 2017 at 3:42 PM, Philip Withnall <philip tecnocode co uk> wrote:
> On Fri, 2017-06-23 at 13:26 -0400, Colin Walters wrote:
> > On Fri, Jun 23, 2017, at 10:12 AM, Krzesimir Nowak wrote:
> > > > Storing it in commit metadata means that the collection ref is
> > > > signed
> > > > as a part of the commit, so we can trust it from the start. But
> > > > it
> > > > also means that we need to specify the collection ref from the
> > > > beginning and it can never change (that would change the commit's
> > > > checksum) - that makes the --orphan flag a whole lot less useful.
> > > > Also
> > > > it is not fine when ostree refs have discontinuous history (ref
> > > > pointed to commit 1, then later it points to commit 2 which is
> > > > not a
> > > > child of commit 1, so commit 1 is not a part of ref's history).
> >
> > I've been advocating for doing content and not commit promotion,
> > like https://github.com/cgwalters/ostree-releng-scripts/blob/master/d
> > o-release-tags
> >
> > It does mean commit checksums become a bit less meaningful in
> > general,
> > but I think there's a big difference between "production" repos and
> > transient
> > commits in a testing pipeline that humans may never run.
> >
> > So think storing it in the commit metadata itself is best to so we
> > don't
> > need yet another signature mechanism.
>
> That all makes sense. Are you happy with the fact that putting refs in
> the commit metadata basically makes `ostree refs --delete` worthless,
> since those ref references in the commit metadata can never be deleted?
> I guess we could sidestep that by defining the commit metadata as “the
> list of refs the commit belonged to *when it was written*” which makes
> the potential lack of freshness obvious.
>
> > > 1. Do we want to store not one collection ref, but many of them in
> > > the
> > > commit metadata? I wasn't sure whether we should allow for many
> > > collection refs there or rather for one collection id and many
> > > refs.
> > > Philip argued for the former.
> >
> > Supporting multiple may make sense...though it feels like the use
> > case would overlap a lot with the endoflife rebase?
>
> Not sure how it overlaps much with EOL rebase. With EOL rebase, two
> branches which were previously separate are merged at one point, and
> then one of them dies. So there’s only going to be at most one commit
> which is on both branches (and, more likely, zero commits, since the
> EOLed branch will end with an empty commit containing the rebase
> metadata).
>
> Support for multiple refs in the commit metadata is more about the
> situation where a series of commits belong to two branches. For
> example, when branching off a version, there might be several commits
> which are shared between $version_branch and master before they
> diverge. Is that realistic use case?

I guess that each branch could have their own commits that point to
the same toplevel .dir{tree,meta} objects. Also, if we move collection
ref information to commit metadata then we need to know that both
branches should reference this commit at the moment of creation of the
commit. So I guess what would be more useful in this case is to have a
flag for ostree commit (like "--contents-from=<commit>") that tells
ostree to create a new commit with the same directory contents as the
other commit, but with different metadata.

I just read some "ostree commit --help" output, and probably "ostree
commit --tree=ref=<commit>" does exactly that…

> > > 2. As a part of the metadata we store the timestamp, which tells
> > > when
> > > this particular piece of metadata was modified. I guess that the
> > > only
> > > useful check we can perform with it is to compare it with the
> > > timestamp from the older detached metadata of the commit (if we had
> > > it
> > > before). Anything else comes to your mind?
> >
> > This and below aren't necessary if the metadata is inline, right?
>
> Correct, I think.
>
> Philip
>
> > > 3. I wasn't sure if we want to bail out when the detached metadata
> > > is
> > > invalid or just skip this commit. Bailing out is easier, so this is
> > > what I went with for now.
> > > 4. If we set the collection ref for a commit, should we also set it
> > > for all its parent commits too?
> >
> > _______________________________________________
> > ostree-list mailing list
> > ostree-list gnome org
> > https://mail.gnome.org/mailman/listinfo/ostree-list
>
> _______________________________________________
> ostree-list mailing list
> ostree-list gnome org
> https://mail.gnome.org/mailman/listinfo/ostree-list



-- 
Kinvolk GmbH | Adalbertstr. 6a, 10999 Berlin
Geschäftsführer/Directors: Alban Crequy, Chris Kühl, Iago López Galeiras
Registergericht/Court of registration: Amtsgericht Charlottenburg
Registernummer/Registration number: HRB 171414 B
Ust-ID-Nummer/VAT ID number: DE302207000