Are the WOF endpoints working?

[SRGDamia1]

The WOFpy endpoints seem to have cut out in January. That's the last time the CUAHSI WDC was able to index us. The last time the dataset indices in TSA was updated was also in January.. though the actual data available on TSA is roughly current.

[aufdenkampe]

Thanks for heads up! We'll add that to our bug fix milestone.

…

Sent from my iPhone On Apr 24, 2019, at 5:47 PM, Sara Damiano <[email protected]<mailto:[email protected]>> wrote: The WOFpy endpoints seem to have cut out in January. That's the last time the CUAHSI WDC was able to index us. The last time the dataset indices in TSA was updated was also in January.. though the actual data available on TSA is roughly current. - You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#379>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ABHNHVD57R2SFAIDJGZAFK3PSDPO5ANCNFSM4HIIOTUA>.

[aufdenkampe]

@SRGDamia1, this is not related to our issues with sparkline plots and TSA, as WOFpy interacts directly with the ODM2 database in PostgreSQL.

[aufdenkampe]

These URL's should show us if it is working:

• http://data.envirodiy.org/wofpy
• http://data.envirodiy.org/wofpy/rest/1_1/GetSiteInfo?site=envirodiy:160065_Limno_Crossroads

[SRGDamia1]

Doesn't TSA get its data from WOFpy?

[aufdenkampe]

TSA originally did get it's data from WOFpy/WaterML1.1, but because that was so slow, USU decided to implement InfluxDB.

TSA now gets all its data values from InfluxDB, and it uses a separate tsa_catalog schema in PostgreSQL for its metadata. That tsa_catalog DB gets populated from the ODM2 schema using a Django command.

[SRGDamia1]

So many broken pieces...

[aufdenkampe]

Yes...
I think we found the issue. We found this [need to open port 8080] in the WOFpy code, but it was missing from the server config info that we received in January.

[emiliom]

I think we found the issue. We found this in the WOFpy code, but it was missing from the server config info that we received in January.

I assume that by "this" you mean the port 8080 issue ...

(from your email) I looks like opening port 8080 didn't fix it on it's own. See https://github.com/LimnoTech/ODM2DataSharingPortalConfig/issues/11

It seems like we need to start the service or something, but I'm not sure how to do that. If you could help us, that would be great. We would then add those commands to our startup shell script(s).

Ok. I'll start looking into it on Monday or Tuesday. Where do you want me to track progress and follow up? On this issue / repo, or on the private one at https://github.com/LimnoTech/ODM2DataSharingPortalConfig?

[aufdenkampe]

@emiliom, yes, I was referring to our need to have port 8080 open for WOFpy on the web servers. As I mentioned in my email, we fixed that, but that alone didn't fix it.

Let's move the conversation over the issue in our private repo at https://github.com/LimnoTech/ODM2DataSharingPortalConfig/issues/11, as that's where we're describing the gory details of our deployment.

[aufdenkampe]

Quick update: @emiliom has deployed a clean, updated version of WOFpy on our development servers at https://staging.monitormywatershed.org/wofpy/.

It's ready for testing!

[emiliom]

Any reason to keep this issue open, when we have this one:
https://github.com/LimnoTech/ODM2DataSharingPortalConfig/issues/12
That's where I've been reporting my progress and documenting findings.

Not sure it's worth anyone's time to test that WOFpy endpoint right now. We pretty much know the answer already: the service is up, but most requests end in time outs.

[aufdenkampe]

@emiliom, thanks for that summary of where we're at.
I agree that we should close this issue and work on the performance improvements elsewhere.

[emiliom]

This issue was about WOFpy not working at all on the EnviroDIY server, not performance per se. Getting WOFpy working again was/is the focus of https://github.com/LimnoTech/ODM2DataSharingPortalConfig/issues/12

I agree that we should close this issue and work on the performance improvements elsewhere.

See ODM2/WOFpy#228, where I tracked past discussions and issues previously brought up. It doesn't look like I ever opened a follow up, more specific issue on performance improvements within https://github.com/ODM2/ODM2DataSharingPortal or https://github.com/LimnoTech/ODM2DataSharingPortalConfig. I can do that later.