Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   "Benjamin Coddington" <bcodding@redhat.com>
To:     "Linux NFS Mailing List" <linux-nfs@vger.kernel.org>,
        NFSv4 <nfsv4@ietf.org>
Subject: virtual/permanent bakeathon infrastructure
Date:   Mon, 04 Jan 2021 08:46:34 -0500
Message-ID: <85C06BBD-2861-4CDE-BCED-ACD974560D3A@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

How are folks feeling about throwing time at a virtual bakeathon?  I had
some ideas about how this might be possible by building out a virtual
network of OpenVPN clients, and hacked together some infrastructure to make
it happen:

https://vpn.nfsv4.dev/

That network exists today, and any systems that are able to join it can use
it to test.  There are a number of problems/complications:
    - the private network is ipv6-only by design to avoid conflicts with
      overused ipv4 private addresses.
    - it uses hacked-together PKI to protect the TLS certificates encrypting
      the connections
    - some implementations of NFS only run on systems that cannot run
      OpenVPN software, requiring complicated routing/transalations
    - it needs to be re-written from bash to something..  less bash.
    - network latencies restrict testing to function; testing performance
      doesn't make sense.

With the ongoing work on NFS over TLS, my thought now is that if there is
interest in standing up permanent infrastructure for testing, then that's
probably sustainable way forward.  But until implementations mature, its not
going to help us host a successful testing event in the near future.

So, the second question -- should we instead work towards implementations of
NFS over TLS as a way of creating a more permanent testing infrastructure?

I am aware that I am leaving out a lot of detail here in order to try to
start a conversation and perhaps coalesce momentum.

Happy new year!
Ben