Implement WOFPy for Production Database

[horsburgh]

Need a working instance of WOFPy for the production database behind data.envirodiy.org so that we can implement the Time Series Analyst.

[aufdenkampe]

@sreeder, can you let us (@emiliom, @lsetiawan, @SRGDamia1 and I) know the status on this effort, given the recent encouraging emails? It would be great to have a WOFpy endpoint to begin testing.

[horsburgh]

Here’s the URL that Stephanie sent me for the WOFPy service on top of the data.envirodiy.org ODM2 database:

http://odm2wofpy.uwrl.usu.edu:8080/odm2timeseries/

This instance is on a Linux VM that I will move to our production virtualization infrastructure once we have verified that this is all working correctly.

[SRGDamia1]

The link is not working for me.

[horsburgh]

@SRGDamia1 - working on this. We've got some power issues in our machine room that have taken machines down in the last couple of days. I'm traveling so it's been tough to troubleshoot.

[horsburgh]

@SRGDamia1 - it's back up, but there's a chance that it will go back down again. We've been having some power bumps at the Water Lab where this machine is located, and I've discovered that the batteries in the UPS system that this virtualization host is on need to be replaced. So - any power bump takes down any machines running on this host. Apologies for the inconvenience. The production machine will eventually get moved up to USU's enterprise data center.

[horsburgh]

This issue is technically complete. However, the instance of WOFPy we have set up on the production database is currently hosted on a machine with a USU URL (url above). We are in the process of moving it to the production server so that it will be under the data.envirodiy.org domain. We are testing on the sandbox first. I'm going to leave this issue open and move it to the next milestone - I will close it when WOFPy is deployed on data.envirodiy.org.

[emiliom]

@horsburgh Before you make your EnviroDIY WOFpy instance more public, I'd strongly recommend that you change the network name/code being used. Currently you'er using the wofpy default, generic "odm2timeseries". As you know, in a broader context (eg, WDC catalog) the network name becomes an identifier for your WOF endpoint, so you should strive to make it unique-looking, reasonably descriptive, and reasonably short. eg, EnviroDIYts

Also, looks like your WOFpy instance is broken right now; all the sample requests I tried at http://odm2wofpy.uwrl.usu.edu:8080/odm2timeseries/rest_1_1/ return SQL errors. But it used to work just fine, so I assume the problems are fully on your end 😉

[aufdenkampe]

I like @emiliom's suggestion to change the name, and then to register with WDC. We want this for demos ASAP. @benjamincrary and I also noticed that the current service is down, as we initiated work to develop a little R code and a Shiny app as a demo to display the live data from EnviroDIY. So, it would be great to prioritize all of these tasks.

[horsburgh]

We are working on these now. If you do demos, just know that the URL to the service is going to change soon so that it is under the data.envirodiy.org domain. Not sure why the current endpoint broke. @sreeder is looking at it.

[horsburgh]

@emiliom - good suggestion on renaming the network name. We'll change that to "envirodiy". FYI - we don't know why the WOFPy service quit working. We hadn't made any changes at all. @sreeder restarted the service, and it started working again. We're wondering if there is an issue in WOFPy with runnning for long time periods? I hope not, but it didn't quit because of anything we did.

[emiliom]

FYI - we don't know why the WOFPy service quit working. We hadn't made any changes at all. @sreeder restarted the service, and it started working again. We're wondering if there is an issue in WOFPy with runnning for long time periods? I hope not, but it didn't quit because of anything we did.

Hmm. I don't think we've run into that problem. I guess it'd have to be a combination of length of time and level of usage? What I can tell you is that we've had two wofpy test instances on our Amazon cloud server for a while, and they haven't spontaneously crashed. @lsetiawan, have you noticed a problem like that?

[horsburgh]

@sreeder - this issue can be closed when we move the WOFPy service to the production server. I'm assuming you are ready to do that as part of the next deployment (or have written instructions so someone can do it in your absence)?

[horsburgh]

Sandbox instance of the latest WOFPy deployment for envirodiy is at:

http://envirodiysandbox.usu.edu/wofpy/

[emiliom]

Cool, @horsburgh! Two comments (cc'ing @lsetiawan):

• You're using "wofpy" as the network code. That's a terrible choice in the long-run 👎
• I did manual tests on the REST 1.1 sample page/services. I ran into some errors and got intrigued to do some probing. The site/location being used for all tests, 160065_CROSSLANDS (I've dropped the network code), uses a different case from what's actually stored in the database -- what's stored (which you can access from the GetSites request) looks like this: 160065_Crosslands. Once you make this manual replacement, all requests work, except possibly one. Here's the successful GetSiteInfo request. Anyway, this brings up a couple of questions/comments:
  • First, and somewhat trivially, your wofpy configuration file should be updated so the selected sample site name/code is in the right case.
  • More broadly, does WOF 1.1 specify if the strings in requests (either SOAP or REST) should be interpreted as case sensitive? It looks like WOFpy is doing case-sensitive matching. We should change that if WOF 1.1 specifically says it should be case-insensitive

[lsetiawan]

What I can tell you is that we've had two wofpy test instances on our Amazon cloud server for a while, and they haven't spontaneously crashed. @lsetiawan, have you noticed a problem like that?

I haven't seen any problems like that before. The only breakage was the rollbacks before, but that should be fixed already.

[aufdenkampe]

I like the suggestion from @emiliom to change the network code from "wofpy".
@emiliom, what do you suggest?

I also like the suggestions to get the case situation corrected. Last, we want to change the site code for this exemplar site (to "160065_Limno_Crossroads") but we want to do it when you are ready to change the example, so we don't have our examples fail. Please let me and @benjamincrary know when you are ready for us to change the name.

[emiliom]

I like the suggestion from @emiliom to change the network code from "wofpy".
@emiliom, what do you suggest?

Well, I'll just repeat the suggestion I made on Aug 2: EnviroDIYts. But really, that's up to y'all in the EnviroDIY project. As I said then, I think the driver should be to strive to make it unique-looking, reasonably descriptive, and reasonably short.

I also like the suggestions to get the case situation corrected. Last, we want to change the site code for this exemplar site (to "160065_Limno_Crossroads") but we want to do it when you are ready to change the example, so we don't have our examples fail. Please let me and @benjamincrary know when you are ready for us to change the name.

You can change the case in the database or in the WOFpy config file. I think it's far easier and less drastic to change in the config file. With Stephanie out, @lsetiawan can hand-hold you if you'd like (Don, this would fall under the "DRB/WikiWatershed/WilliamPenn" project).

[fryarludwig]

It looks like all the action items here are completed.