* virtual/permanent bakeathon infrastructure
@ 2021-01-04 13:46 Benjamin Coddington
2021-01-04 13:56 ` [nfsv4] " Chuck Lever
0 siblings, 1 reply; 5+ messages in thread
From: Benjamin Coddington @ 2021-01-04 13:46 UTC (permalink / raw)
To: Linux NFS Mailing List, NFSv4
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
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [nfsv4] virtual/permanent bakeathon infrastructure 2021-01-04 13:46 virtual/permanent bakeathon infrastructure Benjamin Coddington @ 2021-01-04 13:56 ` Chuck Lever 2021-01-05 16:49 ` Steve Dickson 2021-01-05 20:13 ` Olga Kornievskaia 0 siblings, 2 replies; 5+ messages in thread From: Chuck Lever @ 2021-01-04 13:56 UTC (permalink / raw) To: Benjamin Coddington; +Cc: Linux NFS Mailing List, NFSv4 > 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. > 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [nfsv4] virtual/permanent bakeathon infrastructure 2021-01-04 13:56 ` [nfsv4] " Chuck Lever @ 2021-01-05 16:49 ` Steve Dickson 2021-01-05 20:13 ` Olga Kornievskaia 1 sibling, 0 replies; 5+ messages in thread From: Steve Dickson @ 2021-01-05 16:49 UTC (permalink / raw) To: Chuck Lever, Benjamin Coddington; +Cc: Linux NFS Mailing List, NFSv4 Happy New Year!! On 1/4/21 8:56 AM, Chuck Lever 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. The last week in Feb 22 to 26 should be do-able... > > >> 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. I would strongly suggest, if you are planning on attending, you jump on the network Ben has build to deal with any configurations issue. > > >> 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. Isn't this what these events for? To bring early implementations so they can be harden. But not having a clue as to the current condition of the RPC-over-TLS code, I'll leave that up to whomever... BTW, where is the current RPC-over-TLS code? > > >> 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. +1 > > >> 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.Thanks for starting the conversation! steved. >> >> 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 > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [nfsv4] virtual/permanent bakeathon infrastructure 2021-01-04 13:56 ` [nfsv4] " Chuck Lever 2021-01-05 16:49 ` Steve Dickson @ 2021-01-05 20:13 ` Olga Kornievskaia 2021-01-06 21:46 ` Rick Macklem 1 sibling, 1 reply; 5+ messages in thread From: Olga Kornievskaia @ 2021-01-05 20:13 UTC (permalink / raw) To: Chuck Lever; +Cc: Benjamin Coddington, Linux NFS Mailing List, NFSv4 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [nfsv4] virtual/permanent bakeathon infrastructure 2021-01-05 20:13 ` Olga Kornievskaia @ 2021-01-06 21:46 ` Rick Macklem 0 siblings, 0 replies; 5+ messages in thread From: Rick Macklem @ 2021-01-06 21:46 UTC (permalink / raw) To: Olga Kornievskaia, Chuck Lever; +Cc: Linux NFS Mailing List, NFSv4 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@umich.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 know the content is safe. If in doubt, forward suspicious emails to IThelp@uoguelph.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> 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 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www.ietf.org/mailman/listinfo/nfsv4 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2021-01-06 21:47 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-01-04 13:46 virtual/permanent bakeathon infrastructure Benjamin Coddington 2021-01-04 13:56 ` [nfsv4] " Chuck Lever 2021-01-05 16:49 ` Steve Dickson 2021-01-05 20:13 ` Olga Kornievskaia 2021-01-06 21:46 ` Rick Macklem
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.