[Systems] migrating to beam rider

[David Farning]

On Fri, Oct 16, 2009 at 7:41 PM, Bernie Innocenti <bernie at codewiz.org> wrote:
> [cc += systems@]
>
> El Fri, 16-10-2009 a las 17:46 -0500, David Farning escribió:
>> A couple of things I worked on today
>> --Migrating services to beamrider.
>> My thoughts are to start with:
>> 1. activities.sl.o - production application
>> 2. activities.sl.o. - production memcached instance
>>
>> I was looking around and is it going to be a pain in the butt to move.
>
> The good news is that beamrider was created from a rib of sunjammer not
> long ago, so all we have to do resync the files that were changed since
> them (and the database).

Why rsync everything? Maybe I misunderstand what you mean by
everything.  One of the goals for migrating is to clean up
actiivities.sl.o so it will be easy to replicate across multiple
machines.

1. Create /srv/www-sugarlabs/activities on beamrider by pulling from
the git repo.
2. Copy activities.sl.o config files from sunjammer to beam rider.
3. Insure proper apache mod are installed and enabled on beamrider.
4. Copy the apache activities.conf file from sunjammer to beamrider.
Edit as needed
5. Copy /etc/logrotate.d/activities from sunjammer to beamrider.  Edit
as needed.

Questions.
In order to scale activities.sl.o across multiple front ends it will
be necessary for each front end to mount
/srv/www-sugarlabs/activities/files/ and
srv/www-sugarlabs/activities/repo/ from a common mount point.  Is
setting up a NFS mount the best way to do this?

If this is hard, we can post pone it until later and just copy the
directories.  The advantage of setting up the common mount point now
is that we can share a common database instance, memcache instance,
and file directories.  By doing this, we can point activities2.sl.o at
beamrider for testing.  From a user pov a.sl.o and a2.sl.o will be
exactly the same.  To go live we just need to flip a switch to point
a.sl.o from sunjammer to beam rider.

6. Set up cron job to rsync from common
srv/www-sugarlabs/activities/repo/ to /srv/uploads/activites.

>>  The big win would be if we left the a.sl.o database and download.sl.o
>> on sunjammer.  This would require that we got all of the a.sl.o module
>> abstractions right.  We took some shortcuts setting up a.sl.o the
>> first time because we did not know what we are doing.
>
> I see.
>
>
>> I would rather not move mirrorbrain to beamrider.  We are going to be
>> doing quite a bit of work on the mirror brain packages over the next
>> couple of weeks.  If we are going to have beamrider and sunjammer be
>> tier 1 and tier 2 machines, it might make sense not to move
>> mirrorbrain until it has stabilized.
>
> Agreed.  Moreover, the *upload* directory at least needs to be on
> sunjammer so that users can actually put things in it.

This is also a argument for setting up upload as a NFS for now.

>> --Launchpad
>> I got the development version running on my desktop last night.  Could
>> not get stable to run on either my desktop or the vm you made.  I'll
>> try again next week.
>
> Would using Karmic help? I wanted to test a Jaunty to Karmic upgrade
> anyway.

If you get a chance to make a fresh karmic VM for
launchpad.sugaabs.org, I will retest the install.

>> --download.sl.o cleanup
>> It looks there ate a couple of thing that we should clean up on dl.sl.o.
>
> Good.
>
Let's wait until after moving a.sl.o to cleanup dl.sl.o.  When we get
the NFS filesystems in place, that will take care of the technicle
issues the rest of the cleanups would be policy driven.  Those can
happen later.

david