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;
MIME-Version: 1.0
References: <85C06BBD-2861-4CDE-BCED-ACD974560D3A@redhat.com> <72FFA566-311D-4826-9F4A-29AE0F379327@oracle.com>
In-Reply-To: <72FFA566-311D-4826-9F4A-29AE0F379327@oracle.com>
From:   Olga Kornievskaia <aglo@umich.edu>
Date:   Tue, 5 Jan 2021 15:13:03 -0500
Message-ID: <CAN-5tyHSs+Qu4pY+Vh+KsNrQzzVzziyYLAHxEMQE=eHtmrTgtA@mail.gmail.com>
Subject: Re: [nfsv4] virtual/permanent bakeathon infrastructure
To:     Chuck Lever <chuck.lever@oracle.com>
Cc:     Benjamin Coddington <bcodding@redhat.com>,
        Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
        NFSv4 <nfsv4@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Mon, Jan 4, 2021 at 8:56 AM Chuck Lever <chuck.lever@oracle.com> wrote:
>
>
>
> > On Jan 4, 2021, at 8:46 AM, Benjamin Coddington <bcodding@redhat.com> wrote:
> >
> > 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/
>
> 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.

Netapp is also saying that they will only allocate hardware for
testing for a given period of time and not indefinitely. Thus, having
an agreed upon date would be a good idea (even if it's a flexible
date).

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