[Bf-committers] BF coordination meeting notes - 2019.08.12

[Brecht Van Lommel]

I think involving ZFS is more complicated and system dependent than it
needs to be. We should start storing the last N buildbot builds
anyway, instead of always overwriting. Linking to a slightly older
build from the download page should not be a problem then.

On Mon, Aug 12, 2019 at 8:08 PM Dan McGrath <danmcgrath.ca at gmail.com> wrote:
>
> Hi,
>
> On Mon, Aug 12, 2019 at 8:00 AM Brecht Van Lommel <brechtvanlommel at gmail.com>
> wrote:
>
> > The idea would be to have a flow like this for example. I think it
> > would help to get better quality reports, or to help users find
> > solutions themselves in some cases.
> >
> > https://docs.google.com/document/d/1gxuBv6aeZjKgzMQmGYdaERKbd7VnllSa9s_ejl2hMGo/edit#bookmark=id.83ndneimph3m
>
>
> Regarding the "Buildbot" section from the above Google doc:
>
> > It would be good if a serious bug is introduced, we have an easy way to
> > pin the buildbot download page to an earlier version without that bug until
> > it is fixed.
>
>
> Actually, this could potentially be possible using ZFS snapshots. The
> directory is already available to the jail itself, so it would be a matter
> of just rsync'ing back over the current contents of the download directory
> -- which is what the PHP script enumerates, IIRC -- with the contents of
> one of the snapshots. This could be done by had, or programatically, as
> needed. Of course, the downside to merely rsync'ing back over top of the
> current files, is that the next build bot run will replace the files again,
> but this could possibly be the easiest to implement a "temp fix" by just
> sym linking the broken file(s) to their /.zfs/snapshots/ alternative,
> submitting the patch in advance, and then letting the next buildbot run
> replace it. Not exactly the best solution, when you don't have strict
> control to prevent builds from rolling out, mind you.
>
> I would suggest at least creating a dataset in ZFS for just those files,
> and modifying the current site to use symbolic links to point to an
> alternate location, for as long as is needed. This might require some
> tweaks to the PHP file that we use now (to ensure it follows the sym link),
> but I don't see why this couldn't work. It also has the benefit of not
> requiring extra permissions to the jail itself, just a one time creation of
> a new dataset.
>
> There is also the possibility of allowing for the ZFS dataset to be
> manipulated from within the jail itself, thus allowing a script to say,
> create or delete snapshots on the download directory, but I would generally
> recommend against this, at least with the current design that we have for
> jail configuration.
>
>
> Cheers,
>
> Dan
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers