Add coverage_name parameter to the "create_coverage_resource" function in geoserver_engine.py

[shawncrawley]

I am having to rename a bunch of files before uploading them to GeoServer through the "create_coverage_resource" function to ensure that they are named what I'd like them to be. I noticed that the GeoServer API allows a 'coverageName' parameter to be passed to it that will determine the resource's (layer's) name. This would save me (and maybe others) a lot of trouble. Depending on if the imagepyramid addition gets approved, this one completely requires the coverageName parameter, or else the resulting layer is always name 'pyramid'.

This fix requires about 3 lines of code, which I have implemented and tested locally. I could make the pull request if desired.

[swainn]

+1

[alansnow21]

+1

[Dan Ames]

Are Tethys apps Django apps?

What will it take to simplify deploying apps on, for example, a playground.?

I'm at cuahsi meeting right now and the question has arised....

[swainn]

Tethys apps are modular, but they are not Django apps. Tethys itself is composed of several Django apps. You can think of Tethys apps as extensions for the Tethys Django apps (unfortunately "app" is overloaded here).

I'm not completely sure what is meant by "playground", but I imagine you mean "how can we install apps without logging onto the server". No? Here is some background that may shed some light.

Tethys apps themselves are  like any Python package you would find on PyPI and they include a setup script (setup.py) that is used to install the app and it's dependencies. This means that apps are setup well to have installation automated. If the installation and setup is entirely automated and triggered from the setup script, then the following workflow could be feasible:

1. The user uploads an archive with their app through the admin portal or some other page on Tethys Portal (.zip or .tar.gz)

2. The archive is unpacked and the setup script is run automatically, installing the app

3. The Apache server is reloaded automatically

However, it gets a little more complicated if the app uses any of the Tethys services (i.e. GeoServer). Currently, the admin needs to know to create a GeoServer services with a certain name that the app expects (e.g. "default_geoserver"), but this can be done in the admin portal, so it would just necessitate an additional step:

4. Setup necessary services required by app.

However, we have plans to change how services are handled in Tethys. Instead of the developer of the app dictating that they need a GeoServer named such and such, the developer would instead specify that they need a GeoServer (or two or three) for their app to work--essentially creating slots for a GeoServer to plug into. Then the admin of the portal would be able to assign any GeoServer service that is available. Presumably, we could have a "default" GeoServer instance that would be plugged into any app that needs it automatically. The point of all this is that step 4 could be dropped out.

Whether this workflow works or not depends a lot on the dependencies of the app. If the app requires any extra system dependencies or manual setup steps, then this won't work. We could try to anticipate the system dependencies problem and install any commonly needed system dependencies with Tethys when it is installed (e.g. netcdf, gdal). Also, if two apps have conflicting dependencies (like different versions of the same dependency) there could be issues there... so it may be necessary to create a way to manage the dependencies from the front end.

[Dan Ames]

OK this makes sense. Thanks for clarifying. I'll forward your notes to Alva Couch who was asking this, but I don't think he's on this mailing list. Also, if all goes well we should have funding some time in the next year to build an "App Store" where portal managers can retrieve apps to use in their portal. I think this will require more of an automated app install approach that handles the issues you've laid out... - Dan

--
You received this message because you are subscribed to the Google Groups "Tethys Platform" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tethysplatfor...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tethysplatform/0bd51edf-ab94-43f5-bd99-adf67ee2ab73%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.