[Systems] Pootle 2.5 porting [Work in Progress]

[Bernie Innocenti]

+rralcala
+rgs

On 07/03/2013 04:11 PM, Aneesh Dogra wrote:
> Hey List,
> 
> I have finally ported our ancient pootle to pootle 2.5 (with all
> translation and database files) and it seems to be working. Check
> http://newpootle.sugarlabs.org/
> 
> The next job is to start porting pootle-helpers and make them work on
> 2.5. If someone can give me a starting point it would be greatly
> helpful. Are there any scripts that might not be useful anymore?
> 
> Pootle 2.5 also includes some new inbuilt scripts like commit_to_vcs,
> which of course commits and pushes translation changed to the linked
> code repository [git/svn/vcs], so it probably supersedes our version in
> pootle-helpers.
> 
> Any inputs welcome.

I'm very happy to hear that you've (almost) succeeded in bringing us an
up-to-date Pootle instance! Many before you struggled with this
difficult migration.

Unfortunately, I won't be able to help you with the next phase because
I'll be on vacation from Jul 4 to Jul 10 (see my post to systems@).

Roberto might be able to help you, as he had expressed interest in
helping with Pootle. Aleksey also has lots of experience running
production services and integrating git with other things.

Checklist for you and whoever assists you:

 - have you tried rebooting the service to see if it stays up?

 - have you tried loading the service with some queries or crawling
   it with wget -R to see if it has enough memory?

 - what monitoring do you need? munin?

 - are logs being rotated? any log spew?

 - backups? never transition a VM to production before you have
   good backups

 - documentation? is the wiki up to date?

 - try migrating all data from old pootle to new pootle once.
   how long does it take? make sure nothing has been lost
   or corrupted during the migration.

 - announce the day and time of the cut-off on this list and
   maybe cc sugar-devel@

 - ensure the CNAME translate.sugarlabs.org has a reasonably
   short ttl

 - on the announced time, put the production instance in read-only

 - sync the data one last time, verify the result one last time

 - switch the CNAME in the DNS

 - wait until the change propagates

 - announce the end of the outage

 - wait for people to complain about the fallout

 - after a few days, recycle the old VM

Of course, if anything goes wrong at any time, you must be able to go
back to the previous state. Sysadmin safely! :-)

-- 
Bernie Innocenti
Sugar Labs Infrastructure Team
http://wiki.sugarlabs.org/go/Infrastructure_Team