Re: [Learning Registry: Collaborate] Re: Problem with (re-)installation of node

[Steve Midgley]

Switching over to the -dev group which I think has more people who will have thoughts about this. (bcc to collaborate list so anyone interested there will sign up to learningreg-dev to follow along).

Just guessing here (until the west coast wakes up) but I think your file "/home/learningregistry/git/LearningRegistry/LR/development.ini" has some problems? It seems like python is trying to load key/value config pairs out of this file. Maybe you are running in dev mode (so it's loading the dev ini) but you only have a production config file set up?

This is a WAG -- Walt and Jim (and others) will know more for sure.

Steve

On Mon, Feb 25, 2013 at 10:01 AM, John Gilbertson <jo...@smiggle.org.uk> wrote:

Hi Jim,

I'm the server admin here at Liverpool who's been tasked with looking after the OS/software side of things.

I've tried almost everything short of wiping the system and starting completely from scratch, and we keep getting what I think is the same error when trying to access the /status page of LR which I've been told is a good indication of the health of the LR system.

I believe the uWSGI log shows where the error is ocurring: http://pastebin.com/0Tkdu2JS

Unfortunately I'm not really well versed in Python so the errors mean very little to me in terms of debugging what might be causing the issue.

If you could provide any pointers I'd be thoroughly grateful

John Gilbertson

Computing Services Department

The University of Liverpool

On Friday, 22 February 2013 14:18:29 UTC, Andy Green wrote:

Hello everyone,
We're having a few problems over this side of the pond in reinstalling our LR node at Liverpool University. Our ENGrich project (described in the JISC/JLeRN case studies on the Learning Registry) is developing a visual media search engine built upon a local LR node.

To date, we have been running off the Mimas node at the University of Manchester, from whom we've enjoyed a great deal of support. Towards the end of 2012, we successfully installed and tested a node here in Liverpool. We published a few dozen documents and the basic access services (slice, harvest, obtain) worked fine, as did some customised extract data services.

We are now ready to publish tens of thousands of documents and before doing so, wiped our node clean. We encountered no problems at all publishing our documents, but when it came to retrieving them with anything other than <node>/harvest/getrecord?by_doc_ID=TRUE&request_ID=<doc_ID> we got a Server 500 Error. It was also at that point that we realised that <node>/status was returning the same error, indicating something was amiss.

Since then, we've tried reinstalling the node from scratch, but the problem persists. When running yolk -l, there is no mention of LearningRegistry or couchdb even though they're obviously on the system and being run (otherwise we wouldn't be able to publish).

We realise that you'll need more technical details, which our colleague in Computing Services can provide, but before doing so wondered if there is anyone willing/able to help.

Best regards,

Andrew Green
Department of Engineering
The University of Liverpool

Director, Materials e-Learning Technologies Ltd

--
--
You received this message because you are subscribed to the Google
Groups "Learning Registry: Collaborate" group.
 
To post: learning-regis...@googlegroups.com
To unsubscribe:learning-registry-co...@googlegroups.com
 
For more options, visit this group at
http://groups.google.com/group/learning-registry-collaborate?hl=en?hl=en
 
---
You received this message because you are subscribed to the Google Groups "Learning Registry: Collaborate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to learning-registry-co...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Jim Klo]

Hi John,

So it looks like some sub package dependency has changed… We've had this happen with WebOb before which is why we fixated the version to 1.1.1.

For the time being… if you edit the LearningRegistry/LR/setup.py and change the WebOb==1.1.1 to WebOb==1.2.3, you can then run `pip install --upgrade -e LearningRegistry/LR/`

It should start up from there. We'll update the requirement in the next release.

- Jim

Jim Klo

Senior Software Engineer

Center for Software Engineering

SRI International

t. @nsomnac

On Feb 28, 2013, at 3:09 AM, John Gilbertson <jo...@smiggle.org.uk>

 wrote:

Hi All,

In the end we decided it might be quicker to just completely wipe the VM we're working in and start form scratch with a completely clean LR install.

I followed the Linux install instructions as before, but unfortunately at the very last command there seems to be an issue with versions of "WebOb". The LR install gets version 1.1.1 but something is demanding >1.2. Installing 1.2.4 then makes it complain that it's expecting version 1.1.1, and so on. I'm guessing some external library has been updated isnce those instructions were written and it's now causing a conflict?

Here's the output when trying to run uwsgi at the start, and after updating WebOb: http://pastebin.com/a28WSGB9

Any ideas?

Thanks,

John.

To unsubscribe:learning-registry-collaborate+unsubscribe@googlegroups.com

 
For more options, visit this group at
http://groups.google.com/group/learning-registry-collaborate?hl=en?hl=en
 
---
You received this message because you are subscribed to the Google Groups "Learning Registry: Collaborate" group.

To unsubscribe from this group and stop receiving emails from it, send an email to learning-registry-collaborate+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
You received this message because you are subscribed to the Google Groups "Learning Registry Developers List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to learningreg-d...@googlegroups.com.

[John Gilbertson]

Hi Jim,

Ah that's the bunny. I've managed to get LR up and running again. Now to get ourlocal services added on to it and get data into it.

Many thanks for your time and help.

John Gilbertson
Computing Services Department
The University of Liverpool

[Steve Midgley]

Great - thanks Jim and John. John when/if you want to start replicating your data with your LR nodes please let us know so we can set that up.

Now that federated update/delete are about to roll out, it should be relatively painless to federate your data and get rid of stuff or update it later if you want.

One key note on that is to ideally store the LR envelope doc_id's for the data you send, which will make precise update/deletes way easier. These can be looked up later (by resource locator URL or other keyword pattern) too but easier if you're providing them when you publish or recording them if your node is auto-issuing them on publish.

We currently recommend providing your own doc_id's and making them URN's with your domain, id's and other unique elements (time stamp for example) in them.

Steve

[Andy Green]

Jim,

Thanks very much for pointing John in the right direction. We'd been struggling with this for over a week now, so a huge relief to have our node back up again.

 

Steve, we're scheduled to run a trial of our Kritikos visual media search engine with students over the next 6 weeks or so. Once we're happy that we're collecting the right kind of paradata, we would certainly be interested in the idea of replicating it.

 

Good luck to all with rolling out the new update/delete version.

 

Best regards,

 

Andrew