[SAC] SVN/Trac VM

[christopher.schmidt at nokia.com]

On May 26, 2010, at 10:19 AM, ext Frank Warmerdam wrote:

> christopher.schmidt at nokia.com wrote:
>> SVN and LDAP can be moved separately from each other, right? I assume that
>> we want to have a separate VM for SVN, which presumably will either need to
>> be the same VM as trac, or have a shared disk with trac. Have we specced
>> that or set it up?
> 
> Chris,
> 
> Just to confirm the plan is to have one VM for Trac and SVN.  I see in
> the table it was listed with 100-200GB and 8GB of RAM.   We have quite a
> bit of RAM so if 8GB might be helpful for performance, I think it is worth
> allocating to this task.

Gotcha. I don't think that there is going to be a lot of difference between 4GB and 8GB; with our current setup, we're not even pushing 2GB most of the time (since I adjusted Apache children ages ago) and seperating out Drupal/PHP from the webserver serving Trac/SVN will leave us even less memory-per-apache child. I'm happy to go with either 4GB or 8GB and 100GB of disk, especially since we can re-allocate later.

> I also wanted to note that our current Trac has custom hacks to use the
> OSGeo LDAP, which I did.  It might be possible to use built-in LDAP
> support in the future, or I may need to reintroduce those changes in
> whatever newer Trac we deploy.  I am happy to help with this particular
> part.

Currently, for trac LDAP integration, we just use LDAP as an authentication (verifying who a user is), correct? If that's the case, it looks the http://trac-hacks.org/wiki/LdapPlugin can solve that need. Once we get a VM set up, I'll experiment to see if I can confirm that.

I've edited the wiki page to set the disk to 100GB, and left the RAM at 8GB, since we're still vastly under the limit for RAM. Currently, the number of CPUs is listed as 2. In general, we have anywhere from 6-8 active SVN requests, so having more CPU would probably not hurt, but I don't understand how CPUs work in this environment; I assume that we don't have to match the total 'CPUs used' on the system to the number of actual cores, and can exceed that. If someone can confirm that, I'd bump that number of virtual CPUs to 4 instead of 2.

Regards,
-- 
Christopher Schmidt
Nokia