Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Modify DAP2 tests to no longer use test.opendap.org #1451

Closed
DennisHeimbigner opened this issue Aug 2, 2019 · 8 comments
Closed

Modify DAP2 tests to no longer use test.opendap.org #1451

DennisHeimbigner opened this issue Aug 2, 2019 · 8 comments
Assignees
@WardF
Labels
area/DAP2 area/DAP4
Milestone
future

Comments

@DennisHeimbigner
Copy link
Collaborator

At least one test (ncdap_test/test_zero_len_var.sh) is using
the test.opendap.org server. There might be others.
It might be better if all of these tests
were modified to use our remote test server.
re: #1449 (comment)
@WardF WardF added this to the future milestone Aug 5, 2019
@xylar xylar mentioned this issue Dec 23, 2019
Merged
5 tasks
@xylar
Copy link

xylar commented Dec 23, 2019

It seems like the test.opendap.org server has been down again for a few days. We're trying to support more systems for libnetcdf on conda-forge but can't really make headway at the moment. So we'd be keen to see the move away from test.opendap.org happen.

@DennisHeimbigner
Copy link
Collaborator Author

Have you contacted opendap support?
I hate to remove or tests that use the opendap
server because it checks that our code has not become
specific to our remotetest server. If this continues to'
be a problem, then we will have to talk to the opendap
people about it.

@xylar
Copy link

xylar commented Dec 23, 2019

I'm contacting them now. I saw the previous issue from Aug 2 and got the impression that this might be a frequent issue.

@xylar
Copy link

xylar commented Dec 23, 2019

It seems like we (as a community) just need to ping them if we find the server to be down. OpenDAP staff maybe don't necessarily notice when the server goes down. Here's what I just heard back:

Should be up now.

Please don't hesitate to let us know if you find it down in the future.

@DennisHeimbigner
Copy link
Collaborator Author

My experience has been that their server is pretty reliable
and does not go down often.

@xylar
Copy link

xylar commented Dec 23, 2019

Okay, that's very good to hear.

@Dave-Allured
Copy link
Contributor

Suggestion. Make DAP tests adaptive. If remote opendap.org server is not responding, then fall back and complete the test suite using the Unidata test server.

Also provide an option, probably a configure option, to disable fallback, and require the opendap.org server.

This is because you have two competing objectives. One is to make it easier for user builds to prove their DAP functionality, and reduce gratuitous test suite failures. The other is as Dennis said earlier, "check that our code has not become specific to our remote test server". Users do not usually care about this latter objective, I think. Thus the default test behavior should be forgiving of single server failures.

@DennisHeimbigner
Copy link
Collaborator Author

Dave makes an excellent point about server failures. I will attempt to
modify our tests so that server failures warn but otherwise pretend
to succeed. This puts a burden on Unidata to detect such cases,
but will hide spurious failures from users.

DennisHeimbigner added a commit to DennisHeimbigner/netcdf-c that referenced this issue Dec 31, 2019
@DennisHeimbigner
Avoid spurious test failures when servers fail.
7223c4a 
re: Unidata#1451

The situation with the various DAP (and other) remote test
servers is currently in a state of flux.  For example, Unidata
admin is planning to forcibly shift the remote test server to
remotetest.unidata.ucar.edu soon.  In addition, the server
test.opendap.org has shown some recent instability.

The result is that various DAP (and byterange) tests can fail
unexpectedly. This is an irritant to users and reveals nothing
about test sucess or failure.

Solve by modifying tests to report server inaccessibility and
otherwise pretend to succeed.

This puts an onus on Unidata to detect such server failures, but
will not cause users to see spurious failures. [Note. Do similar
fix for netcdf-java]. The check is:
1. export SETX=1 to cause all the shell scripts to trace
2. search the log files for the phrase "WARNING" (in upper case)
and see if it is complaining about not finding a server.

Misc. Changes
-------------
1. Added a pingurl program to see if a server was up.
2. modified some test case url targets
@DennisHeimbigner DennisHeimbigner mentioned this issue Dec 31, 2019
Merged
@WardF WardF self-assigned this Jan 2, 2020
@WardF WardF closed this as completed Jan 2, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@WardF WardF

Labels
area/DAP2 area/DAP4
Projects
None yet
Milestone
future
Development

No branches or pull requests
4 participants
@DennisHeimbigner @xylar @WardF @Dave-Allured