Deploying few Piers - options

Hi,

what would be suggested path if one wants to deploy few low traffic
Piers? All Piers in one image or one image per Pier?

Davorin Rusevljan
http://www.cloud208.com/
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

Hi Davorin,

It's technically possible to deploy one image with several
distributions. I've already deployed a few ones. This reduces
significantly the deployment costs. However, you may need to tweet
parts of the code. However, as I've done this a few months ago, I
unfortunately can't tell you where and what may exactly need changes.

Cheers,
Reza

At 16:50 29/04/2011, Davorin Rusevljan wrote:
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

Am 29.04.2011 um 16:50 schrieb Davorin Rusevljan:

> Hi,
>
> what would be suggested path if one wants to deploy few low traffic
> Piers? All Piers in one image or one image per Pier?

If you are talking about low traffic this sounds like multiple kernels in one image is the easiest to do. You don't have multiple piers or pier distributions but multiple kernels that are attached two different paths via PRPierFrame. That is really easy to do and fast enough.

Norbert


_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

The following would be a starting point (not tested):

PRDistribution >> register: aString
         PRKernel reset.
         PRPierFrame
                 registerAsApplication: aString
                 kernel: self kernel

PRDistribution register: 'pier1'.
PRDistribution register: 'pier2'.
PRDistribution register: 'pierN'.

Each call to #register: (variant of exiting #register method)
registers a different Pier distribution. But, as far as I remember,
they share all by default the same 'files' folder.

Hoping this helps,
/Reza

At 16:50 29/04/2011, you wrote:
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

Am 01.05.2011 um 17:46 schrieb Reza Razavi:

Calling register this way is not advizable. As you can see it does 'PRKernel reset'. This will empty the instances on the PRKernel class side. You will end up having multiple kernels attached to PRPierframes as handler but only the last one will be attached to the instances of PRKernel. You're not able to e.g. select it from the configuration panel in seaside anymore. Using it without the reset is indeed a good idea.

About the "files" folder. Pier uses Magritte and Magrittes MAExternalFileModel has a class side setting for the directory and path to use. So you are right, having all kernels in the same image means to share all files in the filesystem within the same directory. But I don't think this is a problem. You can easily divide them afterwards by having a visitor collecting the files for each kernel.

I did this in my gemstone pier exporter utility: http://norbert.hartl.name/blog/pier-export-import-util-for-gemstone/ .

Norbert


_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

Hi Norbert,

I wanted just Davorin to have a pointer where to start with, and
thanks for your additional precisions. So, to summarize, we have
something like:

PRDistribution >> register: aString
         PRPierFrame
                 registerAsApplication: aString
                 kernel: self kernel

PRKernel reset. "to get ride of unwanted existing kernels"
PRDistribution new register: 'pier1'.
PRDistribution new register: 'pier2'.
PRDistribution new register: 'pierN'.

As mentioned before, I've not tested this script, since I actually
use different objects (different distribution builder, kernel, and frame).

Cheers,
Reza
 

_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

Thanks for all inputs!

Are there any unexpected repercussions on persistence that I need to
worry about? (I use ImageBased persistence currently)

Davorin Rusevljan
http://www.cloud208.com/
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

Am 02.05.2011 um 11:03 schrieb Davorin Rusevljan:

> Thanks for all inputs!
>
> Are there any unexpected repercussions on persistence that I need to
> worry about? (I use ImageBased persistence currently)
>
You need to think about your persistence strategy. A image based persistence is tied to a kernel and every write to a kernel will trigger its image based persistence. But it will save the whole image. If you have a lot of kernels than all of them might try to write the image to disk. If you have low traffic than you might have even lower writes in your pier kernel. Thus making the problem a rather theoretical one. But you might want to think of it.

Norbert



_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

At 11:03 02/05/2011, Davorin Rusevljan wrote:
>Are there any unexpected repercussions on persistence that I need to
>worry about? (I use ImageBased persistence currently)

Nothing special to report, as far as I can remember now, but does not
means zero risk.

Basically, the (Debian) server contains:
- one image and associated files, including the 'files' folder.
- several virtual host configurations, one per distribution (in my
configurations), which redirect http requests to the corresponding
seaside/pier distribution/application.

The image is automatically saved, each time one of the distributions
is modified. This works technically fine, but the risk is to save
your image with corrupted objects. For example, I had troubles with
the search widget (on pages that contain text copied from a word document).

All in all, AFAIK, this method is less frequently used for deploying
Pier distributions. So, I'd recommend the follwoings:
- double check some critical routines, including persistence,
- configure both your server and image for a remote (emergency)
access via VNC, and
- backup regularly your image + files

Hoping this helps,
Cheers,
Reza




_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki