Re: Yocto Project SState Mirror discussion

Richard Purdie

On Tue, 2022-06-14 at 07:08 -1000, Steve Sakoman wrote:
At today's Yocto Project Technical Team Meeting Armin raised a
question about the proper way to set up local.conf to use the Yocto
Project state mirror for dunfell. This email is intended to bring
those not attending up to speed and trigger further discussion.

Armin pointed out that the sstate mirror setup section in
local.conf.sample seemed to be in error, and a subsequent web search
didn't yield any useful information on how to proceed. So at a minimum
we have a documentation issue!

Further discussion ensued, and from memory the following points were made:

1. A number of issues have been addressed in the master and kirkstone
branches which significantly improve the usability of the published
project sstate mirror. These improvements are not present in dunfell.

2. There are also improvements in progress for the infrastructure
exporting the sstate mirror.

3. On the autobuilder there are separate development sstate caches for
master, dunfell, and kirkstone. While not strictly necessary, this
was done to isolate potential sstate corruption to single branches.

4. The published sstate mirror is generated at release time, i.e. the
sstate cache from development builds is not used for the release

There was also some discussion about next steps, and Richard suggested
this email to trigger a wider discussion. Potential steps:

1. Improve/fix the sstate cache section of local.conf.sample

2. Improve documentation of sstate cache setup

3. Consider a single sstate cache for all branches on the autobuilder

4. Consider a single sstate mirror for all branches

Hopefully others who attended the meeting can jump in if I missed or
misrepresented anything!
I've been thinking about this and also talking with Michael Halstead
about what makes sense from a mirror/server perspective. Going forward
we going to rename to and place the sstate output from all
builds into there.

We'd drop the release specific sstate directories and the "all"
directory would age artefacts that hadn't been used in a build for X
time such that older ones are deleted.

This makes things much easier for a user to configure as there is one
directory. It makes things easier to mirror too, even if the mirror
does become a bit more changable.

This does mean that over time, release minimal eSDKs would stop working
as their sstate would age out and disappear. I'm not sure I'm going to
worry too much about that.

We'll leave a compatibility link in place for /dev/. We'll need to
update the autobuilder configurations to match these changes and drop
the sstate part of the release process.

The docs changes Armin/Steve mention should then be straightforward.



Join { to automatically receive all group messages.