[Automated-testing] Exporting an OverlayFS as NFS

[Hernandez, Carlos]

Kieran,
Thanks for sharing. We do use NFS for the majority of our automated tests.
Carlos

-----Original Message-----
From: automated-testing-bounces at yoctoproject.org [mailto:automated-testing-bounces at yoctoproject.org] On Behalf Of Kieran Bingham
Sent: Friday, February 16, 2018 4:24 AM
To: automated-testing at yoctoproject.org
Subject: [Automated-testing] Exporting an OverlayFS as NFS

Hi Farmers:

In the recent LWN article: https://lwn.net/Articles/746791/ there is an excerpt highlighting that Overlay file systems can now (or will soon) export over NFS...

I've been waiting for this for a long time...:

================================================================================
Filesystems and block I/O

    Overlay filesystems using overlayfs can now be exported via NFS. Enabling this functionality changes some overlayfs behavior and can create a filesystem that is not backward compatible; see the documentation in (this commit [0]) and (this commit [1]) for details.

[0] https://git.kernel.org/linus/f168f1098dd9038daaf9f7be5f81cdea4985886a
[1] https://git.kernel.org/linus/a01f64b5c06ca1130b0b72ceb5e2a25e4d37ab08
================================================================================
(Thanks to Geert for highlighting this article to me)

Looks like more detail available at : https://lwn.net/Articles/736677/ too.


We've had a recent thread looking at SD card mux devices - but how many of us use NFS as our root for our board farms?

The LWN topic excites me - because now I see a way towards having 'cheap'
individual copies of a root filesystem for every *boot session* of a board.


My vision here is that 'the farm controller', before powering up a board could prepare a fresh 'filesystem' by using a base (like a docker image), and creating a new location for the overlay to be handled. This unique overlay would then be passed as the NFS-Root.

This then leaves the option of either keeping the filesystem state changes (only files modified, or tests files created) after a test has run, or simply discarding all changes if it was a disposable run.

A first implementation of using this could be quite basic:
  Create new mount point $NFS_NEW
  Mount overlay from base at $NFS_NEW
  Boot $BOARD @ $NFS_NEW


But I could imagine features creeping in to an extent that the base filesystem could be handled like docker images (maybe we could even use the docker infrastructure to share rootfs base images):

  farm-root pull arm-minimal

Want to boot a full X environment? Prebuilt userspace?

  farm-root pull ubuntu-arm:18.04

(I now can't get it out of my head that the tool would obviously be called
tractor: 'tractor pull ubuntu-arm:latest')


Only really posting this to raise awareness of what I think is a very useful feature coming to us in v4.16 - and perhaps raise some discussion on desired features - or perhaps to discover that no one really uses NFS root anymore; because 96boards didn't put an Ethernet connector on the design.


I think there's certainly scope to build some useful tools on top of NFS exported overlays though.


Regards
--
Kieran
--
_______________________________________________
automated-testing mailing list
automated-testing at yoctoproject.org
https://lists.yoctoproject.org/listinfo/automated-testing