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;
Content-Type: text/plain;
        charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Subject: Re: [nfsv4] virtual/permanent bakeathon infrastructure
From:   Chuck Lever <chuck.lever@oracle.com>
In-Reply-To: <85C06BBD-2861-4CDE-BCED-ACD974560D3A@redhat.com>
Date:   Mon, 4 Jan 2021 08:56:27 -0500
Cc:     Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
        NFSv4 <nfsv4@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <72FFA566-311D-4826-9F4A-29AE0F379327@oracle.com>
References: <85C06BBD-2861-4CDE-BCED-ACD974560D3A@redhat.com>
To:     Benjamin Coddington <bcodding@redhat.com>
Precedence: bulk


> On Jan 4, 2021, at 8:46 AM, Benjamin Coddington <bcodding@redhat.com> =
wrote:
>=20
> 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:
>=20
> https://vpn.nfsv4.dev/

My colleague Bill Baker has suggested we aren't going to get the
rest of the way there until we have an actual event; ie, a moment
in time where we drop our everyday tasks and focus on testing.

So, I'm all for a virtual event.

We could pick a week, say, the traditional week of Connectathon
at the end of February.


> 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.

And the only RDMA testing we can do is iWARP, which excludes some
NFS/RDMA implementations.


> 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.

The community does need to integrate TLS testing into these events.
However at the moment, there are only a very few implementations. I
don't feel comfortable relying on RPC-over-TLS for general testing
yet.


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

Yes, but given how far away that reality is, we shouldn't delay our
regular testing with the infrastructure you've set up already.


> 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.
>=20
> Happy new year!
> Ben
>=20
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4

--
Chuck Lever