Social Help for Sugar: Week 6

Another week has gone by and my project is mostly working. Last week, I had worked on deployment and after a lot of grief, I was able to able to get a Docker instance running. This week, I had planned on working on database migration scripts – which I did, eventually.

The first thing I did this week was to talk to Paul, asking him about the server space requirements that we’ll have at the time of launch. Paul connected me to Matthew who’s a sysadmin and we’ve discussed some of the details since then. Matthew told me that they’ll have a meeting soon to discuss getting a new VPN for the official deployment.

Then, I decided to clean up a few things. Until now, I had hard-coded the address of the forum. However, that would never work in practice, specially because we’re aiming to get a social-help instance running in every non-internet area. So, I decided to add an option to the control-panel, much like the option for the jabber server. It took me a bit of time but finally, I got round to doing that after a few failures. Now, users can fill in a custom URL for the social-help discussion forum.

The next thing, and a very important thing, was the db migration scripts. The idea is that we’ll have a central repository of information – the central discussion forum running on a subdomain of sugarlabs.org. This central forum will have most of the information. However, as I’ve stated before, we’re making things in such a way that the discussion forum can work even in areas with no connectivity, we’d like to be able to deploy discourse in these areas too. Deployment is pretty easy with docker, as I’ve written in my previous posts. However, these localized discourse instances will be devoid of any information. So, I’m thinking that it will be good to have a way to initialize these new discourse instances with all the information contained in the central repository. That’s why wee needed a db migration script.

Now comes the problem. Taking dump of the running postgres database is easy. The problem is the restoration. To restore the dump, we’ll need to stop the server for a bit. However, to stop the server, we’ll first need to log in to the running docker instance. But, for the docker instance to exist, we’ll need it running! And that’s the dilemma. We can’t have a running server to get a backup but if the we stop the server, the docker instance cannot be logged into. So, I was in a fix.

I tried a couple of things, all to no avail. I was despairing, really. Then, I though maybe the discourse devs had already thought of this problem – what with a new version of discourse coming out every week. And voila! They had thought of it after a few searches on meta.discourse.org, I hit jackpot. There’s a guide that shows exactly how to do this thing. So, I was saved again by the foresight of the discourse developers. Thanks guys!

This next week, I guess that I’ll get a final review from Paul and start working on a code review. Then, with some hope, Matthew will have the server space for me and we’ll probably be able to officially launch this thing.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s