The future of the Remotetest server

[DennisHeimbigner]

Currently, it is the case that the netcdf-4 library has some DAP2 and DAPA4 tests for testing access to a remote server.
In this case, it is the server at remotetest.unidata.ucar.edu.
These tests are important because they verify that the netcdf-c code can properly access remote servers, which is
of course the raison d'etre of DAP2 and DAP4.

There are problems with using remotetest:

1. It is built using netcdf-java/TDS so it co-mingles netcdf-c and netcdf-java.
2. It is a burden on the Unidata staff to ensure that remotetest is always up so users of netcdf-c can successfully run all of our netcdf-c test case.
3. The process for upgrading the remotest server is somewhat complex and is poorly documented (my bad).

On the plus side remotetest helps our users to verify the correctness of their installation as well as providing us with potential bug reports.

Taking the long view, I can see no other option to keeping remotetest running. Anything else requires the user to setup -- somehow -- a server as part of the testing of netcdf-c. This seems too great a burden.

One possibility is to get remotetest off of using netcdf-java and using some other platform that has wide acceptance. But in order to do this, we would need to use a new implementation of a DAP2 and DAP4 server.
At the moment, the only option that exists is the OPeNDAP Hyrax server.
There are difficulties both because it is no under Unidata control and because its DAP4 implementation differs from the netcdf-java implementation because of holes in the DAP4 specification.

Another possibility is to separate out the DAP2 and DAP4 servlets from netcdf-java and run in a simplified server.
In effect we fork the DAP2/DAP4 code and deliberately let it diverge from netcdf-java.

Comments please.

[tdrwenski]

Hey Dennis, maybe not relevant for your discussion points, but just FYI-- on the netcdf-java side we are getting rid of our test dependencies on gretty and remote test and replacing these with a dockerized version of the dts and d4ts war files using TestContainers.

[DennisHeimbigner]

Yes, I saw that. Thanks.

[WardF]

@DennisHeimbigner The TestContainers infrastructure doesn't necessarily work with C/C++ projects, yet, but what do you think about using a containerized version of remotetest? Tara provided the dockerfile being used:

• https://github.com/Unidata/netcdf-java/blob/maint-5.x/cdm-test-utils/src/main/resources/ucar/unidata/util/test/Dockerfile

There are mechanisms we could use to stand this up on an as-needed basis, if it looks like it would suit.