-
-
Notifications
You must be signed in to change notification settings - Fork 69
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.
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
Provide OGC-specific/semantic health-checks #82
Comments
On writing the above issue I now realize that a more minimal/first implementation could entail to enable a user to extend an |
Further thinking: both Requests (on an OGC-service-endpoint) and Checks (on Requests) are best implemented using a plugin system. As for Requests, I have positive experience using OGC Request Templates, either via plain Python
The advantage is that we need only one Request-handling mechanism. The Each Request template would need to supply at least:
In |
As for Checks we could apply a similar mechanism as Requests: plugins that implement a general mechanism, for example:
Possibly we need a way to indicate an outcome or Verdict of the Checks. The implementation of each Check plugin would be a Python function (or class) with a fixed interface. Also here parameters apply that a user needs to supply in I realize the above is not a quick&dirty implementation and will require quite some development time (hard to estimate, 5-10 days?) but could be preserved once we move to v2. For example the Requests and Checks could be managed via a REST API. |
After discussion on Gitter with @tomkralidis :
|
After some thought the above commit introduces the key classes/framework for plugins to deal with the above requirements. The key concept herein is that of a Probe and its implementation as a A There are the following aspects/phases in this concept:
The above concept (running Probes) is in progress to be tested via unittests in |
Implementation is progressing. One may check at our new "devserver" (that runs "dev branches", edge development) at http://dev.geohealthcheck.org. Before merging into master, there are still some additions to be made:
And Nice to Have:
|
A PR #93 was created and just merged into master branch. |
Result is running on http://demo.geohealthcheck.org As #93 shows, also as "side-effects" (like DB upgrade automation), many changes went in under this issue:
Only "gotcha": when having existing DB, all Probes/Checks need to be added manually.. |
In GHC OGC-resources are checked for a successful
GetCapabilities
response (<title>
element), but sometimes that response may even come from a static file. OGC Services on that endpoint can fail for many reasons, usually one notices onGet
-requests (WMSGetMap
, WFSGetFeature
etc) that the service is "unhealthy" without hard failures e.g. a blank WMS image (with Exceptioninimage
), zero WFS featurecount etc. I realize that generic auto-generated, crawlingGet*
requests are tricky to implement, with unwanted performance impacts caused by random OWS-requests (think of a GetFeature for whole count(r)y).Having a
WWW:LINK
Resource check for Exceptions via issue #19 was a first step, but via this issue we seek to do what one could call OGC-semantic-health-checks on Resources.The basic idea is to assign a checklist to each Resource. As its name implies this is a list of checks to be executed on that Resource during a Run. We can have predefined/default checks like getting a
Capabilities
document sucessfully. As we can never be exhaustive in the kind of tests, individual check-types are best implemented as plugins.Suppose each check-type has a
typeid
, a simple checklist on a WWW:LINK Resource may look like:WWW:LINK
with WMSGetMap
request:For OGC Resources based on an endpoint we need more parameters. For example for a
OGC:WMS
endpoint Resource to check if an image is returned, one needs:Most parameters/properties are needed for building the WMS
GetMap
request. We may need to define requests separately such that they are issued once, and then run the checklist. This will make forWWW:LINK
andOGC:*
Resources a similar implementation. Probably forOGC:*
Resources a user needs to provide a list of requests per Endpoint, e.g. from request-templates first and then compose a checklist, with parameters for these requests.Many more checks can be thought of: minimum filesize (prevent blank images), featurecount, etc For OGC specific XML-based services this would entain response parsing according to XML-schema's via
OWSLib
, so less a need for regexes etc. We can start simple with theWWW:LINK
keyword check using thechecklist
-method.The text was updated successfully, but these errors were encountered: