Hi Chris,

It sounds like a reasonable plan to me.

At first glance, I would say that your #magmaThenFilesystem approach sounds like a better way to go. For sure we need to have the file system copy as a backup, but it seems to me that if we are going to use Magma, then we should just go ahead and use it. Otherwise we would be likely to invite all of the usual problems with keeping multiple levels of "cache" in sync.

Dave

Hi Levente and David (cc:box-admins). I wanted to see if you have any suggestions or feedback for my plan to upgrade the our source.squeak.org SqueakSource instance. My goals are:

- upgrade the image to latest trunk, and VM to latest 32-bit Spur.
- get it out of the chroot environment and running in the normal

environment on box4 - restore the 'mc history' and 'mc origin' functions in the image, permanently this time - ability to connect to the server image via RFB instead of having to kill and restart it - to improve the speed, scalability and reliability

As you know, our SqueakSource codebase is self-managed at http://source.squeak.org/ss. I'm currently testing the code via my own personal SqueakSource server on my LAN with a new subclass of SSStorage, called SSCompositeStorage. The CompositeStorage lets us have multiple storage back-ends attached to one server. This allows two new intermediate configurations between a 100% filesystem-only backend and a 100% Magma-only backend:

#filesystemThenMagma -- reads from the filesystem, foreground

saves to the filesystem, background saves to Magma

#magmaThenFilesystem -- reads from Magma, foreground saves to

Magma, background saves to the filesystem.

I think the former is more conservative while the latter should be better-performing (although I still plan to do some loading benchmarks). For either configuration, the Magma component enables the history on MCDefinitions.

The MagmaSession running inside the server image will require a larger memory footprint for the image.

What do you think?

Thanks, Chris

Hi Chris,

This sounds great. What I would like to see is the use of ssh tunnels to access VNC (the allow remote connections should be disabled at least) and other private stuff on the servers instead of opening ports to the internet. Do you know how much more memory is required for the MagmaSession? We're not short of it on that server, but Spur will also increase the memory usage a bit.

Levente

On Thu, 23 Jun 2016, Chris Muller wrote:

Hi Levente and David (cc:box-admins). I wanted to see if you have any suggestions or feedback for my plan to upgrade the our source.squeak.org SqueakSource instance. My goals are:

• upgrade the image to latest trunk, and VM to latest 32-bit Spur.
• get it out of the chroot environment and running in the normal

environment on box4

• restore the 'mc history' and 'mc origin' functions in the image,

permanently this time

• ability to connect to the server image via RFB instead of having

to kill and restart it

• to improve the speed, scalability and reliability

As you know, our SqueakSource codebase is self-managed at http://source.squeak.org/ss. I'm currently testing the code via my own personal SqueakSource server on my LAN with a new subclass of SSStorage, called SSCompositeStorage. The CompositeStorage lets us have multiple storage back-ends attached to one server. This allows two new intermediate configurations between a 100% filesystem-only backend and a 100% Magma-only backend:

#filesystemThenMagma -- reads from the filesystem, foreground saves to the filesystem, background saves to Magma

#magmaThenFilesystem -- reads from Magma, foreground saves to Magma, background saves to the filesystem.

I think the former is more conservative while the latter should be better-performing (although I still plan to do some loading benchmarks). For either configuration, the Magma component enables the history on MCDefinitions.

The MagmaSession running inside the server image will require a larger memory footprint for the image.

What do you think?

Thanks, Chris