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.

[cehbrecht]

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).

@huard @tomLandry
Do you think it would be useful to have a dedicated WPS service (bird) for the CWT API?

[huard]

@cehbrecht Hum. Yes, I suppose you're right. But there is still a need for a live test server IMO.

[tomLandry]

I think we need a live test server (or only service?) for CWT API. If you look at OGC Testbed-15 Call For Participation, it says "The Testbed-15 solution will be tested with platforms provided by NASA, ESA, and ideally the ESGF." That assumes that once TB-15 is started, whoever get the D124 Deliverable will like us very much if we give a headstart to interoperate with NASA/LLNL stacks and endpoints through the API. For "ESA platforms", that roughly translates to Twitcher in WPS 2.0 REST and enabling the Thematic Exploitation Platform configuration. See here: https://portal.opengeospatial.org/files/?artifact_id=82290#EOPAD

[huard]

A new full implementation of the CWT API backend with PyWPS would be a lot of work.

[tomLandry]

Yes, mucho work. My intention for the OGC-DOE project (in the associated "ESGF Compute" Engineering Report) is to neatly document how it could be done, to broadly design the solution. If it's compelling, there will be participants of OGC's testbed paid to take this in account in their own implementations. Also, that's the type of work we'd like to do in DACCS.