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:   Rick Macklem <rmacklem@uoguelph.ca>
To:     Olga Kornievskaia <aglo@umich.edu>,
        Chuck Lever <chuck.lever@oracle.com>
CC:     Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
        NFSv4 <nfsv4@ietf.org>
Subject: Re: [nfsv4] virtual/permanent bakeathon infrastructure
Thread-Topic: [nfsv4] virtual/permanent bakeathon infrastructure
Thread-Index: AQHW4qAQw029x9f8w0a6E7AmBQGnUqoXfYqAgAH7jYCAAau/dw==
Date:   Wed, 6 Jan 2021 21:46:26 +0000
Message-ID: <YQXPR0101MB09680ED6F9B3E42A963F3586DDD00@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM>
References: <85C06BBD-2861-4CDE-BCED-ACD974560D3A@redhat.com>
 <72FFA566-311D-4826-9F4A-29AE0F379327@oracle.com>,<CAN-5tyHSs+Qu4pY+Vh+KsNrQzzVzziyYLAHxEMQE=eHtmrTgtA@mail.gmail.com>
In-Reply-To: <CAN-5tyHSs+Qu4pY+Vh+KsNrQzzVzziyYLAHxEMQE=eHtmrTgtA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 30285c74-4252-436e-727c-08d8b28c850a
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jan 2021 21:46:26.9585
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: oBOOmqjQv5x1rGnw7mflkMEKenWRZhi1ZYeWyGsMLYyzodAOhZGLvhvUVgDM/kC8AZl2/s8oFZFIf3b44TpOiA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQXPR01MB3557
Precedence: bulk
List-ID: <linux-nfs.vger.kernel.org>
X-Mailing-List: linux-nfs@vger.kernel.org

I do not know if I can solve the logistics of participating,
but I will try to do so.

Last week of Feb. would be good timing for me, since it
would still allow me time to get critical fixes into FreeBSD13.

rick

________________________________________
From: nfsv4 <nfsv4-bounces@ietf.org> on behalf of Olga Kornievskaia <aglo@u=
mich.edu>
Sent: Tuesday, January 5, 2021 3:13 PM
To: Chuck Lever
Cc: Linux NFS Mailing List; NFSv4
Subject: Re: [nfsv4] virtual/permanent bakeathon infrastructure

CAUTION: This email originated from outside of the University of Guelph. Do=
 not click links or open attachments unless you recognize the sender and kn=
ow the content is safe. If in doubt, forward suspicious emails to IThelp@uo=
guelph.ca


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> w=
rote:
> >
> > How are folks feeling about throwing time at a virtual bakeathon?  I ha=
d
> > 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 encryp=
ting
> >      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 performanc=
e
> >      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, it=
s 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 implementatio=
ns of
> > NFS over TLS as a way of creating a more permanent testing infrastructu=
re?
>
> 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 t=
o
> > 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

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4