Live Emu server for public testing

[huard]

Description

I think it would be useful to have a public live emu server that can be used for testing. The server would have both anonymous access and known credentials (testuser, testpassword) so we can test clients.

[cehbrecht]

Needed on the WPS client side testing:
bird-house/birdy#36

[huard]

@tomLandry Is this something CRIM could look at ?

[tomLandry]

Probably, but on the medium-term track. Meaning probably not this summer.

[cehbrecht]

See also: bird-house/bird-house.github.io#24

[huard]

We have that now, right ?

[cehbrecht]

@huard If you mean the one at DKRZ, it is only a demo installation and not maintained for testing. We probably want to have one Emu which is used for testing only and updated from release to release.

[huard]

@tomLandry Is this something CRIM could contribute?

[tomLandry]

Trying to wrap my mind on how/if this is useful for the Compute Challenge.

[huard]

At the moment Emu has a subset process that complies (or should) with the CWT API. One thing we could do is run the certification script on this process, and eventually implement the other services (aggregate, regrid).

More generally, we use Emu to test clients. For example, WPS should in principle work with identifiers that include &;-. and unicode characters. There is a process in Emu with such characters and that revealed bugs in PyWPS, birdy and possibly owslib (unconfirmed). We could use Emu to test security and so on. Emu allows us to create dummy processes that can exercise corner cases, instead of the happy path we restrict ourselves to with production servers.

[tomLandry]

Cool, thanks. I'm currently surveying issues related to ESGF and CWT that are within reach and useful short term - before creating new ones with help of David Byrns. We still have flexibility in how we present that handful of taks to OGC. Of course I have bird-house/birdy#102 and bird-house/birdy#58 on my radar.