siemens / kas

Setup tool for bitbake based projects
MIT License
339 stars 145 forks source link

Use mirrors and shared cache via NFS with kas-container #123

Open redeexpressos opened 3 weeks ago

redeexpressos commented 3 weeks ago

Hi. I'm trying to create an automatic CI/CD pipeline. However, it sometimes fails mid compilation with FETCH error URL. Usually, when this happens locally, I restart it and it works, but in CI/CD this is not acceptable.

From what I understand, there is a possibility to use shared cache (r+w) + mirrors (r) via NFS. My question is, is it possible to set this and use it inside the kas-container? I have a NFS server configured. How can I do this?

fmoessbauer commented 3 weeks ago

Yes, both the DL_DIR, as well as the sstate related variables SSTATE_DIR and SSTATE_MIRRORS are automatically forwarded into the container (SSTATE_DIR is rewritten to match the mount in the container). Just export these variables on the host before calling kas-container. For details, please also see https://kas.readthedocs.io/en/latest/command-line.html#variables-glossary

Regarding NFS: Make sure to also forward the credentials into the container.

bbergquist0930 commented 2 weeks ago

I have the same requirement but still don't understand how to accomplish this.

The kas-container script has

if [ -n "${SSTATE_MIRRORS}" ]; then
    if echo "${SSTATE_MIRRORS}" | grep -q "file:///"; then
        warning "SSTATE_MIRRORS contains a local path." \
                "Make sure to make this path available inside the container."
    fi
    set -- "$@" -e "SSTATE_MIRRORS=${SSTATE_MIRRORS}"
fi

So it warns to make the paths available inside the container, but I don't see any additional way to add the paths into the container. The processing of the SSTATE_DIR sets up to mount a volume into the container, but the SSTATE_MIRRORS processing does not.

Maybe there should be an extra command line parameter to mount additional volumes into the container. Or the SSTATE_MIRRORS could be split and parsed and the file mirrors could be mounted into the container just like the SSTATE_DIR is.

Unless I am missing something obvious?

Maybe as a workaround, I could mount my nfs filesystem into a directory within my working directory which then would be accessible.

jan-kiszka commented 2 weeks ago

Problem is that we would have to parse and translate the elements SSTATE_MIRRORS so that we have local path from host POV and can create mount option for the container runtime. That would be a generic solution. Your private one could be adding --runtime-args '-v <host>:<container>' to your kas-container call. SSTATE_MIRRORS would then have to point to the <container> path.

bbergquist0930 commented 2 weeks ago

Thank you for responding. The --runtime-args is what I was missing. It is documented but I missed it :(